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Description 

[0001] The present invention relates to the field of distribution and usage rights enforcement for digitally encoded 
wori<s. 

5 [0002] A fundamental issue facing the publishing and information industries as they consider electronic publishing 
is how to prevent the unauthorized and unaccounted distribution or usage of electronically published materials. Elec- 
tronically published materials are typically distributed in a digital form and recreated on a computer based system 
having the capability to recreate the materials. Audio and video recordings, software, boolcs and multimedia wori<s are 
all being electronically published. Companies in these industries receive royalties for each accounted for delivery of 

10 the materials, e.g. the sale of an audio CD at a retail outlet. Any unaccounted distribution of a woric results in an unpaid 
royalty (e.g. copying the audio recording CD to another digital medium.) 

[0003] The ease in which electronically published works can be "perfectly" reproduced and distributed is a major 
concern. The transmission of digital works over networks Is commonplace. One such widely used networi< is the In- 
ternet. The Internet is a widespread networic facility by whbh computer users in many universities, corporations and 

15 government entities communicate and trade ideas and infonmation. Computer bulletin boards found on the Intemet 
and commercial networks such as CompuServ and Prodigy allow for the posting and retrieving of digital infonnation. 
Infonnation services such as Dialog and LEXIS/NEXIS provide databases of cun-ent infonnation on a wide variety of 
topics. Another factor which will exaceriDate the situation is the development and expansion of the National Information 
Infrastructure (the Nil). It Is anticipated that, as the Nil grows, the transmission of digital works over networks will 

20 increase many times over. It would be desirable to utilize the Nil for distribution of digital works without the fear of 
widespread unauthorized copying. 

[0004] The most stralghtfonA^ard way to curi? unaccounted distribution is to prevent unauthorized copying and trans- 
mission. For existing materials that are distributed in digital fonn, various safeguards are used. In the case of software, 
copy protection schemes which limit the number of copies that can be made or which corrupt the output when copying 

25 is detected have been employed. Another scheme causes software to become disabled after a predetemnined period 
of time has lapsed. A technique used for woricstation based software is to require that a special hardware device must 
be present on the wori<station in order for the software to run, e.g., see US-A-4,932,054 entitled "IS^ethod and Apparatus 
for Protecting Computer Software Utilizing Coded Filter Networic in Conjunction with an Active Coded Hardware De- 
vice." Such devices are provided with the software and are commonly refen-ed to as dongles. 

30 [0005] Yet another scheme Is to distribute software, but which requires a "key" to enable Its use. This Is employed 
in distribution schemes where "demos" of the software are provided on a medium along with the entire product. The 
demos can be freely used, but in order to use the actual product, the key must be purchased. These schemes do not 
hinder copying of the software once the key is Initially purchased. 

[0006] Document WO-A-92 20022 discloses a system for controlling the distribution and use of digital works using 
35 a digital ticket as defined in the pleamble of claim 1 . 

[0007] It Is an object of the present Invention to provide an improved system and method for controlling the use and 
distribution of digital works. 

[0008] The Invention accordingly provides a system and method as claimed in the accompanying claims. 

[0009] A system for controlling the distribution and use of digital worics using digital tickets is disclosed. A ticket Is 

40 an indicator that the ticket holder has already paid for or is othenwise entitled to some specified right, product or sen/ice. 
In the present Invention, a "digital ticker is used to enable the ticket holder to exercise usage rights specifying the 
requirement of the digital ticket. Usage rights are used to define how a digital work may be used or distributed. Specific 
instances of usage rights are used to indicate a particular manner of use or distribution. A usage right may specify a 
digital ticket which must be present before the right may be exercised. For example, a digital ticket may be specified 

45 in a Copy right of a digital woric, so that exercise of the Copy right requires the party that desires a copy of the digital 
woric be in possession of the necessary digital ticket. After a copy of the digital work is successfully sentto the requesting 
party, the digital ticket is "punched" to indicate that a copy of the digital wori< has been made. When the ticket Is 
"punched" a predetenmined number of times, It may no longer be used. 

[0010] Digital works are stored in repositories. Repositories enforce the usage rights for digital works. Each repository 
50 has a "generic ticket agenf which punches tickets. In some Instances only the generic ticket agent is necessary In 
other instances, punching by a "special ticket agenf residing on another repository may be desired. Punching by a 
"special ticket agenf enables greater security and control of the digital work. For example, it can help prevent digital 
ticket forgery. Special ticket agents are also useful in situations where an external database needs to be updated or 
checked. 

55 [0011] A digital ticket Is merely an instance of a digital work. Thus, a digital ticket may be distributed among repos- 
itories in the same fashion as other digital works. 

[0012] A digital ticket may be used in many commercial scenarios such as in the purchase of software and prepaid 
upgrades. A digital ticket may also be used to limit the number of times that a right may be exercised. For example, a 
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user may purchase a copy of a digital woric, along with the right to make up to 5 Copies. In this case, the Copy right 
would have associated therewith a digital ticket that can be punched up to 5 times. Other such commercial scenarios 
will become apparent from the detailed description. 

[0013] A system and method in accordance with the invention will now be described, by way of example, with refer- 
5 ence to the accompanying drawings, in whlch:- 

Figure 1 is a flowchart illustrating a simple instantiation of the operation of the currently preferred embodiment of 
the present invention. 

Figure 2 Is a block diagram illustrating the various repository types and the repository transaction flow between 
10 them in the cun-ently preferred embodiment of the present Invention. 

Figure 3 Is a block diagram of a repository coupled with a credit server In the currently preferred embodiment of 
the present invention. 

Figures 4a and 4b are examples of rendering systems as may be utilized in the cun-ently preferred embodiment 
of the present invention. 

15 Figure 5 Illustrates a contents file layout for a digital work as may be utilized in the currently preferred embodiment 

of the present invention. 

Figure 6 illustrates a contents file layout for an individual digital work of the digital viork of Figure 5 as may be 
utilized in the cun^entty preferred embodiment of the present invention. 

Figure 7 Illustrates the components of a description block of the currently preferred embodiment of the present 

20 invention. 

Figure 8 illustrates a description tree for the contents file layout of the digital work illustrated In Figure 5. 
Figure 9 illustrates a portion of a description tree corresponding to the individual digital work illustrated in Figure 6. 
Figure 1 0 illustrates a layout for the rights portion of a description block as may be utilized in the currently prefen^ed 
embodiment of the present invention. 
25 Figure 11 is a description tree wherein certain d-blocks have PRINT usage rights and is used to illustrate "strict" 

and "lenient' rules for resolving usage rights conflicts. 

Figure 12 Is a block diagram of the hardware components of a repository as are utilized In the currently prefen^ed 

embodiment of the present invention. 

Figure 13 is a block diagram of the functional (logical) components of a repository as are utilized in the cun-ently 
30 prefenred embodiment of the present Invention. 

Figure 14 Is diagram illustrating the basic components of a usage right In the cun-ently preferred embodiment of 

the present invention. 

Figure 15 lists the usage rights grammar of the currently prefenred embodiment of the present invention. 
Figure 16 is a flowchart Illustrating the steps of certificate delivery, hotlist checking and perfomnance testing as 
35 perfonned in a registration transaction as may be performed In the currently preferred embodiment of the present 

invention. 

Figure 17 is a flowchart illustrating the steps of session infomiation exchange and clock synchronization as may 
be performed In the cun^entty preferred embodiment of the present Invention, after each repository in the registration 
transaction has successfully completed the steps described in Figure 16. 
40 Figure 18 is a flowchart illustrating the basic flow for a usage transaction, including the common opening and 

closing step, as may be perfomned in the currently preferred embodiment of the present invention. 
Figure 1 9 is a state diagram of server and client repositories in accordance with a transport protocol followed when 
moving a digital work from the server to the client repositories, as may be perfomned in the currently preferred 
embodiment of the present invention. 

45 

OVERVIEW 

[0014] A system for controlling use and distribution of digital works is disclosed. The present invention is directed to 
supporting commercial transactions Involving digital wori<s. 

50 [0015] Herein the ternns "digital work", "wori<" and "content" refer to any work that has been reduced to a digital 
representation. This would include any audio, video, text, or multimedia work and any accompanying Interpreter (e.g. 
software) that may be required for recreating the work. The term composite wori< refers to a digital work comprised of 
a collection of other digital works. The term "usage rights" or "rights" is a tenn which refers to rights granted to a recipient 
of a digital work. Generally, these rights define how a digital work can be used and If it can be further distributed. Each 

55 usage right may have one or more specified conditions which must be satisfied before the right may be exercised. 
[0016] Figure 1 is a high level flowchart omitting various details but which demonstrates the basic operation of the 
present Invention. Referring to Figure 1, a creator creates a digital wori<, step 101. The creator will then detemnine 
appropriate usage rights and fees, attach them to the digital woric, and store them in Repository 1, step 102. The 
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determination of appropriate usage rights and fees will depend on various economic factors. The digital work remains 
securely in Repository 1 until a request for access Is received. The request for access begins with a session initiation 
by another repository. Here a Repository 2 Initiates a session with Repository 1, step 103. As will be described In 
greater detail below, this session initiation includes steps which helps to insure that the respective repositories are 

5 trustworthy. Assuming that a session can be established. Repository 2 may then request access to the Digital Work 
for a stated purpose, step 104. The purpose may be, for example, to print the digital work or to obtain a copy of the 
digital work. The purpose will correspond to a specific usage right. In any event, Repository 1 checks the usage rights 
associated with the digital work to detennine if the access to the digital work may be granted, step 105. The check of 
the usage rights essentially involves a determination of whether a right associated with the access request has been 

10 attached to the digital work and If all conditions associated with the right are satisfied. If the access is denied, repository 
1 temnlnates the session with an en^or message, step 1 06. If access is granted, repository 1 transmits the digital work 
to repository 2, step 1 07. Once the digital work has been transmitted to repository 2, repository 1 and 2 each generate 
billing Infomiatlon for the access which Is transmitted to a credit server, step 108. Such double billing reporting is done 
to Insure against attempts to circumvent the billing process. 

15 [0017] Figure 2 illustrates the basic interactions between repository types in the present invention. As will become 
apparent from Figure 2, the various repository types will serve different functions. It is fundamental that repositories 
will share a core set of functionality which will enable secure and trusted communications. Referring to Figure 2, a 
repository 201 represents the general instance of a repository. The repository 201 has two modes of operation; a server 
mode and a requester mode. When in the server mode, the repository will be receiving and processing access requests 

20 to digital works. When in the requester mode, the repository will be initiating requests to access digital works. Repository 
201 Is general in the sense that Its primary purpose Is as an exchange medium for digital works. During the course of 
operation, the repository 201 may communteate with a plurality of other repositories, namely authorization repository 
202, rendering repository 203 and master repository 204. Communication between repositories occurs utilizing a re- 
pository transaction protocol 205. 

25 [0018] Communication with an authorization repository 202 may occur when a digital work being accessed has a 
condition requiring an authorization. Conceptually, an authorization is a digital certifk^ate such that possession of the 
certificate is required to gain access to the digital work. An authorization Is itself a digital wortc that can be moved 
between repositories and subjected to fees and usage rights conditions. An authorization may be required by both 
repositories Involved In an access to a digital work. 

30 [0019] Communication with a rendering repository 203 occurs in connection with the rendering of a digital wori<. As 
will be described in greater detail below, a rendering repository Is coupled with a rendering device (e.g. a printer device) 
to comprise a rendering system. 

[0020] Communication with a master repository 205 occurs in connection with obtaining an identification certificate. 
Identification certificates are the means by which a repository is Identified as "trustworthy". The use of identification 

35 certificates Is described below with respect to the registration transaction. 

[0021] Figure 3 illustrates the repository 201 coupled to a credit server 301 . The credit server 301 is a device which 
accumulates billing infomnation for the repository 201. The credit server 301 communicates with repository 201 via 
billing transactions 302 to record billing transactions. Billing transactions are reported to a billing clearinghouse 303 
by the credit server 301 on a periodic basis. The credit server 301 communicates to the billing clearinghouse 303 via 

40 clearinghouse transactions 304. The clearinghouse transactions 304 enable a secure and encrypted transmission of 
Infomriation to the billing clearinghouse 303. 

RENDERING SYSTEMS 

45 [0022] A rendering system is generally defined as a system comprising a repository and a rendering device which 
can render a digital wori< into its desired form. Examples of a rendering system may be a computer system, a digital 
audio system, or a printer. A rendering system has the same security features as a repository. The coupling of a 
rendering repository with the rendering device may occur in a manner suitable for the type of rendering device. 
[0023] Figure 4a illustrates a printer as an example of a rendering system. Referring to Figure 4, printer system 401 

so has contained therein a printer repository 402 and a print device 403. It should be noted that the the dashed line defining 
printer system 401 defines a secure system boundary. Communications within the boundary are assumed to be secure. 
Depending on the security level, the boundary also represents a bamer intended to provide physical integrity. The 
printer repository 402 is an instantiation of the rendering repository 205 of Figure 2. The printer repository 402 will in 
some instances contain an ephemeral copy of a digital work which remains until it is printed out by the print engine 

55 403. In other instances, the printer repository 402 may contain digital works such as fonts, which will remain and can 
be billed based on use. This design assures that all communication lines between printers and printing devices are 
encrypted, unless they are within a physically secure boundary. This design feature eliminates a potential "faur point 
through which the digital woric could be improperly obtained. The printer device 403 represents the printer components 
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used to create the printed output. 

[0024] Also illustrated in Figure 4a is the repository 404. The repository 404 Is coupled to the printer repository 402. 
The repository 404 represents an external repository which contains digital works. 

[0025] Figure 4b is an example of a computer system as a rendering system. A computer system may constitute a 
5 "multi-function" device since it may execute digital works (e.g. software programs) and display digital works (e.g. a 
digitized photograph). Logically, each rendering device can be viewed as having its own repository, although only one 
physical repository is needed. Referring to Figure 4b, a computer system 410 has contained therein a display/execution 
repository 411 . The display/execution repository 411 is coupled to display device, 412 and execution device 413. The 
dashed box surrounding the computer system 410 represents a security boundary within which communications are 
10 assumed to be secure. The display/execution repository 41 1 is further coupled to a credit server 41 4 to report any fees 
to be billed for access to a digital work and a repository 415 for accessing digital works stored therein. 

STRUCTURE OF DIGITAL WORKS 

15 [0026] Usage rights are attached directly to digital works. Thus, it is important to understand the structure of a digital 
work. The structure of a digital work, in particular composite digital works, may be naturally organized into an acyclic 
structure such as a hierarchy. For example, a magazine has various articles and photographs which may have been 
created and are owned by different persons. Each of the articles and photographs may represent a node in a hierarchical 
structure. Consequently, controls, i.e. usage rights, may be placed on each node by the creator. By enabling control 

20 and fee billing to be associated with each node, a creator of a work can be assured that the rights and fees are not 
circumvented. 

[0027] I n the currently preferred embodiment, the file infonnation for a digital work is divided into two files: a "contents" 
file and a "description tree" file. From the perspective of a repository, the "contents" file is a stream of addressable 
bytes whose fomriat depends completely on the interpreter used to play, display or print the digital work. The description 
25 tree file makes it possible to examine the rights and fees for a work without reference to the content of the digital work. 
It should be noted that the temri description tree as used herein refers to any type of acyclic structure used to represent 
the relationship between the various components of a digital work. 

[0028] Figure 5 illustrates the layout of a contents file. Referring to Figure 5, a digital wori< is comprised of story A 
51 0, advertisement 511, story B 51 2 and story C 51 3. It Is assumed that the digital work is stored starting at a relative 

30 address of 0. Each of the parts of the digital work are stored linearly so that story A 510 Is stored at approximately 
addresses 0-30,000, advertisement 511 at addresses 30,001-40,000, story B 512 at addresses 40,001-60,000 and 
story C 513 at addresses 60,001 -85K. The detail of story A 510 Is illustrated in Figure 6. Referring to Figure 6, the 
story A 510 is further broken down to show text 614 stored at address 0-1500, soldier photo 615 at addresses 
1 501 -1 0,000, graphics 61 6 stored at addresses 1 0,001 -25,000 and sidebar 61 7 stored address 25,001 -30,000. Note 

35 that the data In the contents file may be compressed (for saving storage) or encrypted (for security). 

[0029] From Figures 5 and 6 it is readily observed that a digital work can be represented by its component parts as 
a hierarchy. The description tree for a digital work is comprised of a set of related descriptor blocks (d-blocks). The 
contents of each d-block is described with respect to Figure 7. Referring to Figure 7, a d-block 700 includes an identifier 
701 which is a unique identifier for the work in the repository, a starting address 702 providing the start address of the 

40 first byte of the work, a length 703 giving the number of bytes in the wori<, a rights portion 704 wherein the granted 
usage rights and their status data are maintained, a parent pointer 705 for pointing to a parent d-block and child pointers 
706 for pointing to the child d-blocks. In the cun-ently preferred embodiment, the Identifier 701 has two parts The first 
part Is a unique number assigned to the repository upon manufacture. The second part is a unique number assigned 
to the wortc upon creation. The rights portion 704 will contain a data structure, such as a look-up table, wherein the 

45 various infomnatlon associated with a right Is maintained. The infomnation required by the respective usage rights Is 
described in more detail below. D-blocks fomi a strict hierarchy. The top d-block of a work has no parent; all other d- 
blocks have one parent. The relationship of usage rights between parent and child d-blocks and how conflicts are 
resolved is described below. 

[0030] A special type of d-block is a "shell" d-block. A shell d-block adds no new content beyond the content of its 
50 parts. A shell d-block is used to add rights and fee information, typically by distributors of digital works. 

[0031 ] Figure 8 Illustrates a description tree for the digital work of Figure 5. Referring to Figure 8, a top d-block 820 
for the digital work points to the various stories and advertisements contained therein. Here, the top d-block 820 points 
to d-block 821 (representing story A 510), d-block 822 (representing the advertisement 511), d-block 823 (representing 
story B 512) and and d-block 824 (representing story C 513). 
55 [0032] The portion of the description tree for Story A 51 0 is illustrated In Figure 9. D-block 925 represents text 614, 
d-block 926 represents photo 615, d-block 927 represents graphics 616 by and d-block 928 represents sidebar 617. 
[0033] The rights portion 704 of a descriptor block is further illustrated In Figure 1 0. Figure 1 0 Illustrates a structure 
which is repeated In the rights portion 704 for each right. Refenring to Figure 10, each right will have a right code field 
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1 050 and status information field 1 052. The right code field 1 050 will contain a unique code assigned to a right. The 
status information field 1 052 will contain Information relating to the state of a right and the digital work. Such Information 
is indicated below In Table 1 . The rights as stored In the rights portion 704 may typically be In numerical order based 
on the right code. 

TABLE 1 



DIGITAL WORK STATE INFORMATION 


Property 


Value 


Use 


Copies-in-Use 


Number 


A counter of the number of copies of a work that are In use. Incremented when 
another copy is used; decremented when use is completed. 


Loan-Period 


Time-Units 


Indicator of the maximum number of time-units that a document can be loaned 
out 


Loaner-Copy 


Boolean 


Indicator that the current work is a loaned out copy of an authorized digital work. 


Remaining-Tlme 


Time-Units 


Indicator of the remaining time of use on a metered document right. 


Document-Descr 


String 


A string containing various Identifying inf onnation about a document. The exact 
fonnat of this is not specified, but it can include infonnation such as a publisher 
name, author name, ISBN number, and so on. 


Revenue-Owner 


RO-Descr 


A handle identifying a revenue owner for a digital work. This is used for reporting 
usage fees. 


Publication-Date 


Date-Descr 


The date that the digital work was published. 


History-list 


History-Rec 


A list of events recording the repostories and dates for operations that copy, 
transfer, backup, or restore a digital work. 



[0034] The approach for representing digtal works by separating description data from content assumes that parts 
of a file are contiguous but takes no position on the actual representation of content. In particular, It is neutral to the 
question of whether content representation may tal<e an object oriented approach. It would be natural to represent 
content as objects. In principle, it may be convenient to have content objects that include the billing structure and rights 
infomnation that is represented In the d-blocks. Such variations in the design of the representation are possible and 
are viable alternatives but may Introduce processing overhead, e.g. the Interpretation of the objects. 
[0035] Digital works are stored in a repository as part of a hierarchical file system. Folders (also temied directories 
and sub-directories) contain the digital wori<s as well as other folders. Digital works and folders in a folder are ordered 
In alphabetical order. The digital wortcs are typed to reflect how the flies are used. Usage rights can be attached to 
folders so that the folder itself is treated as a digital work. Access to the folder would then be handled in the same 
fashion as any other digital wori< As will be described in more detail below, the contents of the folder are subject to 
their own rights. Moreover, file management rights may be attached to the folder which define how folder contents can 
be managed. 

ATTACHING USAGE RIGHTS TO A DIGITAL WORK 

[0036] It is fundamental to the present Invention that the usage rights are treated as part of the digital work. As the 
digital woric is distributed, the scope of the granted usage rights will remain the same or may be narrowed. For example, 
when a digital work is transferred from a document server to a repository, the usage rights may include the right to loan 
a copy for a predetemnined period of time (called the original rights). When the repository loans out a copy of the digital 
wori(, the usage rights in the leaner copy (called the next set of rights) could be set to prohibit any further rights to loan 
out the copy. The basic idea is that one cannot grant more rights than they have. 

[0037] The attachment of usage rights into a digital work may occur in a variety of ways. If the usage rights will be 
the same for an entire digital work, they could be attached when the digital work is processed for deposit in the digital 
wortc server. In the case of a digital woric having different usage rights for the various components, this can be done 
as the digital wori< is being created. An authoring tool or digital work assembling tool could be utilized which provides 
for an automated process of attaching the usage rights. 

[0038] As will be described below, when a digital wori< is copied, transferred or loaned, a "next set of rights" can be 
specified. The"next set of rights" will be attached to the digital work as it is transported. 
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Resolving ConHicUng Rights 

[0039] Because each part of a digital work may have its own usage rights, there will be instances where the rights 
of a "contained part" are different fronn its parent or container part. As a result, conflict rules must be established to 
5 dictate when and how a right may be exercised. The hierarchical structure of a digital work facilitates the enforcement 
of such rules. A "strict" rule would be as follows: a right for a part In a digital work is sanctioned If and only if it is 
sanctioned for the part, for ancestor d-blocks containing the part and for all descendent d-blocks. By sanctioned, it is 
meant that (1) each of the respective parts must have the right, and (2) any conditions for exercising the right are 
satisfied. 

10 [0040] It also possible to implement the present invention using a more lenient rule. In the more lenient rule, access 
to the part may be enabled to the descendent parts which have the right, but access is denied to the descendents 

which do not. 

[0041] An example of applying both the strict rule and lenient is Illustrated with reference to Figure 11 . Refemng to 
Figure 11, a root d-block 1101 has child d-blocks 1102-1105. In this case, root d-block represents a magazine, and 

IS each of the child d-blocks 1 1 02-1 1 05 represent articles In the magazine Suppose that a request is made to PRINT the 
digital work represented by root d-block 1101 wherein the strict rule Is followed. The rights for the root d-block 1101 
and child d-blocks 1102-1105 are then examined. Root d-block 1101 and child d-blocks 1102 and 1105 have been 
granted PRINT rights. Child d-block 11 03 has not been granted PRINT rights and child d-block 11 04 has PRINT rights 
conditioned on payment of a usage fee. 

20 [0042] Under the strict rule the PRINT right cannot be exercised because the child d-block does not have the PRINT 
right. Under the lenient rule, the result would be different. The digital works represented by child d-blocks 1102 and 
1 1 05 could be printed and the digital work represented by d-block 1 1 04 could be printed so long as the usage fee is 
paid. Only the digital work represented by d-block 11 03 could not be printed. This same result would be accomplished 
under the strict rule If the requests were directed to each of the Individual digital works. 

25 [0043] The present invention supports various combinations of allowing and disallowing access. Moreover, as will 
be described below, the usage rights grammar pemnits the owner of a digital woric to specify if constraints may be 
imposed on the work by a container part. The manner in which digital works may be sanctioned because of usage 
rights conflicts would be implementation specific and would depend on the nature of the digital worics. 

30 REPOSITORIES 

[0044] In the description of Figure 2, it was indicated that repositories come in various fomns. All repositories provide 
a core set of services for the transmission of digital worths. The manner in which digital wori<s are exchanged is the 
basis for all transaction between repositories. The various repository types differ In the ultimate functions that they 
35 perform. Repositories may be devices themselves, or they may be Incorporated into other systems. An example is the 

rendering repository 203 of Figure 2. 

[0045] A repository will have associated with it a repository identifier. Typically, the repository identifier would be a 
unique number assigned to the repository at the time of manufacture. Each repository will also be classified as being 
In a particular security class. Certain communications and transactions may be conditioned on a repository being in a 

40 particular security class. The various security classes are described in greater detail below. 

[0046] As a prerequisite to operation, a repository will require possession of an identification certificate. Identification 
certificates are encrypted to prevent forgery and are issued by a Master repository. A master repository plays the role 
of an authorization agent to enable repositories to receive digital worics. Identification certificates must be updated on 
a periodic basis, identification certificates are described In greater detail below with respect to the registration trans- 

45 action. 

[0047] A repository has both a hardware and functional embodiment. The functional embodiment is typically software 
executing on the hardware embodiment. Alternatively, the functional embodiment may be embedded In the hardware 
embodiment such as an Application Specific Integrated Circuit (ASIC) chip. 

[0048] The hardware embodiment of a repository will be enclosed In a secure housing which if compromised, may 
50 cause the repository to be disabled. The basic components of the hardware embodiment of a repository are described 
with reference to Figure 12. Referring to Figure 12, a repository is comprised of a processing means 1200, storage 
system 1 207, clock 1 205 and external interface 1 206. The processing means 1 200 is comprised of a processor element 

1201 and processor memory 1202. The processing means 1201 provides controller, repository transaction and usage 
rights transaction functions for the repository. Various functions In the operation of the repository such as decryption 

55 . and/or decompression of digital wori<s and transaction messages are also perfomried by the processing means 1200, 
The processor element 1 201 may be a microprocessor or other suitable computing component. The processor memory 

1202 would typically be further comprised of Read Only Memories (ROM) and Random Access Memories (RAM). Such 
memories would contain the software instructions utilized by the processor element 1 201 in performing the functions 
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of the repository. 

[0049] The storage system 1207 is further comprised of descriptor storage 1203 and content storage 1204. The 
description tree storage 1203 will store the description tree for the digital woric and the content storage will store the 
associated content. The description tree storage 1203 and content storage 1204 need not be of the same type of 
5 storage medium, nor are they necessarily on the same physical device. So for example, the descriptor storage 1203 
may be stored on a solid state storage (for rapid retrieval of the description tree infonnation), while the content storage 
1 204 may be on a high capacity storage such as an optical disk. 

[0050] The clock 1205 is used to time-stamp various time based conditions for usage rights or for metering usage 
fees which may be associated with the digital wori<s. The clock 1205 will have an uninterruptable power supply, e.g. a 

10 battery, in order to maintain the integrity of the time-stamps. The external interface means 1 206 provides for the signal 
connection to other repositories and to a credit server. The external interface means 1206 provides for the exchange 
of signals via such standard interfaces such as RS-232 or Personal Computer Manufacturers Card Industry Association 
(PCMCIA) standards, or FDD!. The extemal interface means 1206 may also provide networi< connectivity. 
[0051] The functional embodiment of a repository is described with reference to Figure 13. Referring to Figure 13, 

15 the functional embodiment is comprised of an operating system 1 301 , core repository services 1 302, usage transaction 
handlers 1303, repository specific functions, 1304 and a user interface 1305. The operating system 1301 is specific 
to the repository and would typically depend on the type of processor being used. The operating system 1301 would 
also provide the basic services for controlling and interfacing between the basic components of the repository. 
[0052] The core repository services 1302 comprise a set of functions required by each and every repository. The 

20 core repository services 1 302 Include the session initiation transactions which are defined in greater detail below. This 
set of services also includes a generic ticket agent which is used to "punch" a digital ticket and a generic authorization 
server for processing authorization specifications. Digital tickets and authorizations are specific mechanisms for con- 
trolling the distribution and use of digital wori<s and are described in more detail below. Note that coupled to the core 
repository services are a plurality of identification certificates 1306. The identification certificates 1306 are required to 

25 enable the use of the repository, 

[0053] The usage transactions handlers 1 303 comprise functionality for processing access requests to digital works 
and for billing fees based on access. The usage transactions supported will be different for each repository type. For 
example, it may not be necessary for some repositories to handle access requests for digital works. 
[0054] The repository specific functionality 1304 comprises functionality that is unique to a repository. For example, 

30 the master repository has special functionality for issuing digital certificates and maintaining encryption keys. The 
repository specific functionality 1304 would include the user interface implementation for the repository. 

Repository Security Classes 

35 [0055] For some digital works the losses caused by any individual instance of unauthorized copying is insignificant 
and the chief economic concem lies in assuring the convenience of access and low-overhead billing. In such cases, 
simple and inexpensive handheld repositories and networic-based workstations may be suitable repositories, even 
though the measures and guarantees of security are modest. 

[0056] At the other extreme, some digital wori<s such as a digital copy of a first mn movie or a bearer bond or stock 
40 certificate would be of very high value so that it is prudent to employ caution and fairly elaborate security measures to 
ensure that they are not copied or forged. A repository suitable for holding such a digital work couid have elaborate 
measures for ensuring physical integrity and for verifying authorization before use. 

[0057] By arranging a universal protocol, all kinds of repositories can communicate with each other in principle. 
However, creators of some works will want to specify that their wori<s will only be transfen-ed to repositories whose 
45 level of security Is high enough. For this reason, document repositories have a ranking system for classes and levels 
of security. The security classes in the currently pretended embodiment are described in Table 2. 



TABLE 2 



REPOSITORY SECURITY LEVELS 


Level 


Description of Security 


0 


Open system. Document transmission is unencrypted. No digital certificate is required for identification. 
The security of the system depends mostly on user honesty, since only modest knowledge may be needed 
to circumvent the security measures. The repository has no provisions for preventing unauthorized 
programs from running and accessing or copying files. The system does not prevent the use of removable 
storage and does not encrypt stored files. 
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TABLE 2 (continued) 





REPOSITORY SECURITY LEVELS 




Level 


Description of Security 


5 


1 


Minimal security. Like the previous class except that stored files are minimally encrypted, including ones 
on removable storage. 


10 


2 


Basic security. Like the previous class except that special tools and knowledge are required to 
compromise the programming, the contents of the repository, or the state of the clock. All digital 
communications are encrypted. A digital certificate is provided as identification. Medium level encryption 
is used. Repository identification number Is unforgeable. 


15 


3 


General security. Like the previous class plus the requirement of special tools are needed to compromise 
the physical integrity of the repository and that modest encryption is used on all transmissions. Password 
protection is required to use the local user interface. The digital clock system cannot be reset without 
authorization. No works would be stored on removable storage. When executing works as programs, it 
runs them in their own address space and does not give them direct access to any file storage or other 
memory containing system code or wori<s. They can access worics only through the transmission 
transaction protocol. 


20 


4 


Like the previous class except that high level encryption Is used on all communications. Sensors are 
used to record attempts at physical and electronic tampering. After such tampering, the repository will 
not perform other transactions until it has reported such tampering to a designated server. 


25 


5 


Like the previous class except that if the physical or digital attempts at tampering exceed some preset 
thresholds that threaten the physical integrity of the repository or the integrity of digital and cryptographic 
ban^iers. then the repository will save only document description records of history but will erase or destroy 
any digital identifiers that could be misused if released to an unscrupulous party. It also modifies any 
ceniTicaies oi auineniiciiy lo inaicaieinai me pnysicai system nas ueen compromisea. ii diso erciseb ine 
contents of designated documents. 


30 


6 


Like the previous class exceptthat the repository will attempt wireless communication to report tampering 

and will employ noisy alarms. 




10 


This would correspond to a very high level of security. This server would maintain constant 
communications to remote security systems reporting transactions, sensor readings, and attempts to 
circumvent security. 



[0058] The characterization of security levels described in Table 2 Is not intended to be fixed. More Important is the 
idea of having different security levels for different repositories. It is anticipated that new security classes and require- 
ments will evolve according to social situations and changes in technology. 



Repository User Interface 



[0059] A user interface is broadly defined as the mechanism by which a user interacts with a repository in order to 
Invoke transactions to gain access to a digital work, or exercise usage rights As described above, a repository may be 
embodied in various forms. The user interface for a repository will differ depending on the particular embodiment. The 
user Interface may be a graphical user interface having icons representing the digital works and the various transactions 
that may be perfonned. The user interface may be a generated dialog in which a user is prompted for infonmation. 
[0060] The user interface itself need not be part of the repository. As a repository may be embedded In some other 
device, the user interface may merely be a part of the device in which the repository is embedded. For example, the 
repository could be embedded in a "card" that is inserted into an available slot in a computer system. The user interface 
may be a combination of a display, keyboard, cursor control device and software executing on the computer system. 
[0061] At a minimum, the user interface must pemnit a user to input information such as access requests and alpha 
numeric data and provide feedback as to transaction status. The user Interface will then cause the repository to Initiate 
thesuitabletransactlonsto service the request. Otherfacets of a partteular user Interface will depend on the functionality 
that a repository will provide. 
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CREDIT SERVERS 

[0062] In the present Invention, fees may be associated with the exercise of a right. The requlrennent for payment of 
fees Is described with each version of a usage right in the usage rights language. The recording and reporting of such 

5 fees is performed by the credit server. One of the capabilities enabled by associating fees with rights is the possibility 
of supporting a wide range of charging models. The simplest model, used by conventional software, Is that there Is a 
single fee at the time of purchase, after which the purchaser obtains unlimited rights to use the work as often and for 
as long as he or she wants. Alternative models, include metered use and variable fees. A single work can have different 
fees for different uses. For example, viewing a photograph on a display could have different fees than making a hardcopy 

10 or Including it in a newly created work. A key to these alternative charging models Is to have a low overhead means 
of establishing fees and accounting for credit on these transactions. 

[0063] A credit server is a computational system that reliably authorizes and records these transactions so that fees 
are billed and paid. The credit server reports fees to a billing clearinghouse. The billing clearinghouse manages the 
financial transactions as they occur. As a result, bills may be generated and accounts reconciled. Preferably, the credit 
15 server would store the fee transactions and periodically communicate via a network with the billing clearinghouse for 
reconciliation. In such an embodiment, communications with the billing clearinghouse would be encrypted for integrity 
and security reasons. In another embodiment, the credit server acts as a "debit card" where transactions occur In "real- 
time" against a user account. 

[0064] A credit server Is comprised of memory, a processing means, a clock, and Interface means for coupling to a 
20 repository and a financial institution (e g. a modem). The credit server will also need to have security and authentication 
functionality. These elements are essentially the same elements as those of a repository. Thus, a single device can 
be both a repository and a credit server, provided that it has the appropriate processing elements for carrying out the 
corresponding functions and protocols. Typically, however, a credit server would be a card-sized system in the pos- 
session of the owner of the credit. The credit server is coupled to a repository and would interact via financial trans- 
25 actions as described below. Interactions with a financial institution may occur via protocols established by the financial 
Institutions themselves. 

[0065] I n the currently pretended embodiment credit servers associated with both the server and the repository report 
the financial transaction to the billing clearinghouse. For example, when a digital work is copied by one repository to 
another for a fee, credit servers coupled to each of the repositories will report the transaction to the billing clearinghouse. 
30 This is desirable in that it Insures that a transaction will be accounted for in the event of some break in the commun Icatlon 
between a credit server and the billing clearinghouse. However, some implementations may embody only a single 
credit server reporting the transaction to minimize transaction processing at the risk of losing some transactions. 

USAGE RIGHTS LANGUAGE 

35 

[0066] The present invention uses statements in a high level "usage rights language" to define rights associated with 
digital works and their parts. Usage rights statements are interpreted by repositories and are used to detemnine what 
transactions can be successfully carried out for a digital work and also to detemnine parameters for those transactions. 
For example, sentences in the language determine whether a given digital woric can be copied, when and how It can 
40 be used, and what fees (if any) are to be charged for that use. Once the usage rights statements are generated, they 
are encoded in a suitable fomn for accessing during the processing of transactions. 

[0067] Defining usage rights In temns of a language in combination with the hierarchical representation of a digital 
woric enables the support of a wide variety of distribution and fee schemes. An example Is the ability to attach multiple 
versions of a right to a work. So a creator may attach a PRINT right to make 5 copies for $1 0.00 and a PRINT right to 
45 make unlimited copies for $100.00. A purchaser may then choose which option best fits his needs. Another example 
Is that rights and fees are additive. So In the case of a composite work, the rights and fees of each of the components 
works is used in determining the rights and fees for the wori< as a whole 

[0068] The basic contents of a right are illustrated in Figure 14. Referring to Figure 14, a right 1450 has a transactional 
component 1461 and a specifications component 1462. A right 1450 has a label (e g. COPY or PRINT) which indicates 

50 the use or distribution privileges that are embodied by the right. The transactional component 1 461 corresponds to a 
particular way in which a digital work may be used or distributed. The transactional component 1461 Is typically em- 
bodied in software Instructions in a repository which implement the use or distribution privileges for the right. The 
specifications components 1 452 are used to specify conditions which must be satisfied prior to the right being exercised 
or to designate various transaction related parameters. In the currently preferred embodiment, these specifications 

55 include copy count 1453, Fees and Incentives 1454, Time 1455, Access and Security 1456 and Control 1457. Each 
of these specifications will be described in greater detail below with respect to the language grammar elements. 
[0069] The usage rights language Is based on the grammar described below. A grammar Is a convenient means for 
defining valid sequence of symbols for a language. In describing the grammar the notation "[a I b I c]" is used to indicate 
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distinct choices among alternatives. In this example, a sentence can have either an "a", "b" or "c". It must include 
exactly one of them. The braces { } are used to indicate optional items. Note that brackets, bars and braces are used 
to describe the language of usage rights sentences but do not appear In actual sentences in the language. 
[0070] In contrast, parentheses are part of the usage rights language. Parentheses are used to group Items together 
5 in lists. The notation (x*) Is used to indicate a variable length list, that Is, a list containing one or more items of type x. 
The notation (x)* is used to Indicate a variable number of lists containing x. 

[0071] Keywords in the grammar are words followed by colons. Keywords are a common and very special case in 
the language. They are often used to indicate a single value, typically an identifier. In many cases, the keyword and 
the parameter are entirely optional. When a keyword is given, it often takes a single Identifier as Its value. In some 

10 cases, the keyword takes a list of identifiers 

[0072] In the usage rights language, time is specified In an hours:mlnutes:seconds (or hh:mm:ss) representation. 
Time zone indicators, e.g. PDTfor Pacific Daylight Time, may also be specified. Dates are represented as year/ month/ 
day (or YYYY/MMM/DD). Note that these time and date representations may specify moments in time or units of time 
Money units are specified In ternis of dollars. 

15 [0073] Finally, in the usage rights language, various "things" will need to Interact with each other. For example, an 
instance of a usage right may specify a bank account, a digital ticket, etc.. Such things need to be Identified and are 
specified herein using the suffix "-ID." 

[0074] The Usage Rights Grammar is listed in its entirety in Figure 15 and is described below. 
[0075] Grammar element 1501 "Digital Work Rights: = (Rights*)" define the digital work rights as a set of rights. 
20 The set of rights attached to a digital work define how that digital work may be transferred, used, performed or played. 
A set of rights will attach to the entire digital work and in the case of compound digital works, each of the components 
of the digital work. The usage rights of components of a digital may be different. 

[0076] Grammar element 1502 "Right: = (Right-Code {Copy-Count} {Control-Spec} {Time-Spec} {Access- 
Spec} {Fee-Spec})" enumerates the content of a right. Each usage right must specify a right code. Each right may 

25 also optionally specify conditions which must be satisfied before the right can be exercised. These conditions are copy 
count, control, time, access and fee conditions. In the currently pretended embodiment, for the optional elements, the 
following defaults apply: copy count equals 1 , no time limit on the use of the right, no access tests or a security level 
required to use the right and no fee is required. These conditions wili each be described in greater detail below. 
[0077] It is important to note that a digital woric may have multiple versions of a right, each having the same right 

30 code. The multiple version would provide alternative conditions and fees for accessing the digital work. 

[0078] Grammar element 1503 "Right-Code : = Render-Code t Transport-Code I File-Management-Codel De- 
rivative-Works- Code Configuration-Code" distinguishes each of the specific rights into a particular right type (al- 
though each right is identified by distinct right codes). In this way, the grammar provides a catalog of possible rights 
that can be associated with parts of digital works. In the following, rights are divided Into categories for convenience 

35 in describing them. 

[0079] Grammar element 1504 "Render-Code : = [ Play : {Player: Player-ID} I Print: {Printer: Prlnter-ID}]" lists 
a category of rights all involving the making of ephemeral, transitory, or non-digital copies of the digital work. After use 
the copies are erased. 

40 • Play A process of rendering or perfomriing a digital work on some processor. This includes such things as 
playing digital movies, playing digital music, playing a video game, mnnlng a computer program, or displaying a 
document on a display. 

• Print To render the woric in a medium that is not further protected by usage rights, such as printing on paper. 

45 [0080] Grammar element 1505 "Transport-Code : = [Copy 1 Transfer I Loan {Remainlng-Rlghts: Next-Set-of- 
Rlght8}]{(Next-Copy-Rights: Next-Set of Rights)}" lists a category of rights Involving the making of persistent, usable 
copies of the digital work on other repositories. The optional Next-Copy-Rights detemriine the rights on the work after 
it is transported. If this is not specified, then the rights on the transported copy are the same as on the original. The 
optional Remainlng-Rlghts specify the rights that remain with a digital work when It is loaned out. If this is not specified, 

50 then the default Is that no rights can be exercised when It Is loaned out. 

• Copy Make a new copy of a work 

• Transfer Moving a work from one repository to another. 

• Loan Temporarily loaning a copy to another repository for a specified period of time. 

55 

[0081] Grammar element 1506 "File-Management-Code: = Backup {Back-Up-Copy-Rlghts: Next-Set -of 
Rlghts}l Restore i Delete I Folder I Directory {Name: Hide-Local I Hide - Remote}{Parts:Hide-Locai I Hide-Re- 
mote}" lists a category of rights involving operations for file management, such as the making of backup copies to 
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protect the copy owner against catastrophic equipment failure, 

[0082] Many software licenses and also copyright taw give a copy owner the right to make backup copies to protect 
against catastrophic failure of equipment. However, the making of uncontrolled backup copies is inherently at odds 
with the ability to control usage, since an uncontrolled backup copy can be kept and then restored even after the 
authorized copy was sold. 

[0083] The File management rights enable the making and restoring of backup copies in a way that respects usage 
rights, honoring the requirements of both the copy owner and the rights grantor and revenue owner. Backup copies of 
work descriptions (Including usage rights and fee data) can be sent under appropriate, protocol and usage rights control 
to other document repositories of sufficiently high security. Further rights pemriit organization of digital works into folders 
which themselves are treated as digital works and whose contents may be "hidden" from a party seeking to detemnine 
the contents of a repository. 



Backup To make a backup copy of a digital work as protection against media failure. 
Restore To restore a backup copy of a digital wori(. 

Delete To delete or erase a copy of a digital work. 

Folder To create and name folders, and to move files and folders between folders. 
Directory To hide a folder or its contents. 



[0084] Grammar element 1507 "Derlvative-Wbrks-Code : [Extract I Embed I Edit {Process: Process-ID}] 
{Next-Copy-Rights : Next-Set-of Rlgiits}" lists a category of rights involving the use of a digital wori< to create new 
wori^s. 



• Extract To remove a portion of a work, for the purposes of creating a new work, 

• Embed To include a work in an existing work. 

• Edit To alter a digital woric by copying, selecting and modifying portions of an existing digital work. 

[0085] Grammar element 1 508 "Configuration-Code : = instaii i UninstafI" lists a category of rights for Installing 
and uninstalling software on a repository (typically a rendering repository.) This would typically occur for the installation 
of a new type of player within the rendering repository. 



• Install: To install new software on a repository. 

• Uninstall: To remove existing software from a repository. 



[0086] Grammar element 1509 "Next-Set-of-Rights: = {(Add: Set-Of-Rights)} {(Deiete: Set-Of-Rights)} {(Re- 
place: Set-Of-Rights)} {(Keep: Set-Of- Rights)}" defines how rights are carried forward for a copy of a digital work. 
If the Next-Copy-Rights is not specified, the rights for the next copy are the same as those of the current copy. Otherwise, 
the set of rights for the next copy can be specified. Versions of rights after Add: are added to the current set of rights. 
Rights after Delete: are deleted from the current set of rights. If only right codes are listed after Delete: . then all versions 
of rights with those codes are deleted. Versions of rights after Replace: subsume all versions of rights of the same type 
in the current set of rights. 

[0087] If Remalning-Rights is not specified, then there are no rights for the original after all Loan copies are loaned 
out. If Remaining-Rlghts is specified, then the Keep: token can be used to simplify the expression of what rights to 
keep behind. A list of right codes following keep means that all of the versions of those listed rights are kept in the 
remaining copy. This specification can be overridden by subsequent Delete: or Replace: specifications. 



Copy Count Specification 



[0088] For various transactions, it may be desirable to provide some limit as to the number of "copies" of the wori< 
which may be exercised simultaneously for the right. For example, it may be desirable to limit the number of copies of 
a digital work that may be loaned out at a time or viewed at a time. 

[0089] Grammar element 1510 "Copy-Count : = (Copies: positive-Integer I 0 I uniimited)" provides a condition 
which defines the number of "copies" of a work subject to the right . A copy count can be 0, a fixed number, or unlimited. 
The copy-count Is associated with each right, as opposed to there being just a single copy-count for the digital work. 
The Copy-Count for a right is decremented each time that a right is exercised. When the Copy-Count equals zero, the 
right can no longer be exercised. If the Copy-Count is not specified, the default is one. 
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Control Specification 

[0090] Rights and fees depend in general on rights granted by the creator as well as further restrictions imposed by 
later distributors. Control specifications deal with interactions between the creators and their distributors governing the 

5 innposltion of further restrictions and fees. For example, a distributor of a digital worl< may not want an end consumer 
of a digital work to add fees or otherwise profit by commercially exploiting the purchased digital work. 
[0091] Grammar element 1511 "Control-Spec: = (Control: {Restrlctable I Unrestrictable} {Unchargeable I 
Chargeable})" provides a condition to specify the effect of usage rights and fees of parents on the exercise of the right 
A digital work is restrictable if higher level d-blocks can impose further restrictions (time specifications and access 

10 specifications) on the right. It is unrestrictable if no further restrtotions can be imposed. The default setting is restrictable. 
A right is unchargeable if no more fees can be Imposed on the use of the right. It is chargeable If more fees can be 
Imposed. The default Is chargeable. 

Time Specification 

IS 

[0092] It is often desirable to assign a start date or specify some duration as to when a right may be exercised. 
Grammar element 1512 "Time-Spec : = ({Fixed-Interval I Sllding-lnterval I Meter-Time} Until: Expiration-Date)" 
provides for specification of time conditions on the exercise of a right. Rights may be granted for a specified time. 
Different kinds of time specifications are appropriate for different kinds of rights. Some rights may be exercised during 
20 a fixed and predetennined duration. Some rights may be exercised for an interval that starts the first time that the right 
is Invoked by some transaction. Some rights may be exercised or are charged according to some kind of metered time, 
which may be split into separate Intervals. For example, a right to view a picture for an hour might be split into six ten 
minute viewings or four fifteen minute viewings or twenty three minute viewings. 

[0093] The temns "time" and "date" are used synonymously to refer to a moment in time. There are several kinds of 
25 time specifications. Each specification represents some limitation on the times over which the usage right applies. The 
Expiration-Date specifies the moment at which the usage right ends. For example, if the Expiration-Date Is "Jan 1 , 
1995," then the right ends at the first moment of 1996. If the Expiration-Date is specified as *forever*, then the rights 
are interpreted as continuing without end. If only an expiration date is given, then the right can be exercised as often 
as desired until the expiration date. 
30 [0094] Grammar element 1513 "Fixed-Interval : = From: Start-Time" Is used to define a predetennined Interval 
that runs from the start time to the expiration date. 

[0095] Grammar element 1514 "Sllding-lnterval : = Interval: Use-Duration" Is used to define an indetemninate (or 
"open") start time. It sets limits on a continuous period of time over which the contents are accessible. The period starts 
on the first access and ends after the duration has passed or the expiration date Is reached, whichever comes first. 
35 For example, if the right gives 1 0 hours of continuous access, the use-duration would begin when the first access was 
made and end 10 hours later. 

[0096] Grammar element 1 51 5 "Meter-Time: = Time-Remaining: Remaining-Use" is used to define a "metertime," 
that is, a measure of the time that the right is actually exercised. It differs from the Sllding-lnterval specification in that 
the time that the digital work Is in use need not be continuous. For example, if the rights guarantee three days of access, 
40 those days could be spread out over a month. With this specification, the rights can be exercised until the meter time 
is exhausted or the expiration date is reached, whichever comes first. 

Remaining-Use: = Time-Unit 
Start-Time: = Time-Unit 
45 Use-Duration: = Time-Unit 

[0097] All of the time specifications include time-unit specifications in their ultimate instantiation. 

Seci/rftyC/ass and Authorization Specification 

50 

[0098] The present invention provides for various security mechanisms to be introduced into a distribution or use 
scheme. Grammar element 1 51 6 "Access-Spec : = ({SC: Security-Class} {Authorization: Authorization-ID*} {Oth- 
er-Authorization: Authorization-ID*} {Ticket: Ticket-ID})" provides a means for restricting access and transmission. 
Access specifications can specify a required security class for a repository to exercise a right or a required authorization 
55 test that must be satisfied. 

[0099] The keyword "SC:" is used to specify a minimum security level for the repositories involved In the access. If 
"SC:" Is not specified, the lowest security level is acceptable. 

[0100] The optional "Authorization:" keyword is used to specify required authorizations on the same repository as 
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the work. The optional "Other-Authorization:" keyword is used to specify required authorizations on the other repos- 
itory in the transaction. 

[0101] The optional "Ticket:" keyword specifies the Identity of a ticket required for the transaction. A transaction 
involving digital tickets must locate an appropriate digital ticket agent who can "punch" or otherwise validate the ticket 

5 before the transaction can proceed. Tickets are described in greater detail below. 

[0102] In a transaction involving a repository and a document server, some usage rights may require that the repos- 
itory have a particular authorization, that the server have some authorization, or that both repositories have (possibly 
different) authorizations. Authorizations themselves are digital works (hereinafter refen^ed to as an authorization object) 
that can be moved between repositories in the same manner as other digital works. Their copying and transferring Is 

10 subject to the same rights and fees as other digital works. A repository is said to have an authorization if that author- 
ization object is contained within the repository. 

[01 03] In some cases, an authorization may be required from a source other than the document server and repository. 
An authorization object referenced by an Authorization-ID can contain digital address infomriation to be used to set up 
a communications link between a repository and the authorization source. These are analogous to phone numbers. 
15 For such access tests, the communication would need to be established and authorization obtained before the right 
could be exercised. 

[0104] For one-time usage rights, a variant on this scheme is to have a digital ticket. A ticket is presented to a digital 
ttoket agent, whose type is specified on the ticket. In the simplest case, a certified generic ticket agent, available on 
all repositories, is available to "punch" the ticket. In other cases, the ticket may contain addressing infomnation for 
20 locating a "special" ticket agent. Once a ticket has been punched, it cannot be used again for the same kind of trans- 
action (unless it is unpunched or refreshed in the manner described below.) Punching includes marking the ticket with 
a timestamp of the date and time it was used. Tickets are digital works and can be copied or transferred between 
repositories according to their usage rights. 

[0105] In the currently prefen-ed embodiment, a "punched" ticket becomes "unpunched" or "refreshed" when it is 
25 copied or extracted. The Copy and Extract operations save the date and time as a property of the digital ticket. When 
a ticket agent is given a ticket, it can simply check whether the digital copy was made after the last time that it was 
punched. Of course, the digital ticket must have the copy or extract usage rights attached thereto. 
[0106] The capability to unpunch a ticket is inportant in the following cases: 

30 • A digital work is circulated at low cost with a limitation that it can be used only once. 

• A digital work is circulated with a ticket that can be used once to give discounts on purchases of other works. 

• A digital wori< is circulated with a ticket (included In the purchase price and possibly embedded in the work) that 
can be used for a future upgrade. 

35 [01 07] In each of these cases. If a paid copy Is made of the digital work (including the ticket) the new owner would 
expect to get a fresh (unpunched) ticket, whether the copy seller has used the work or not. In contrast, loaning a work 
or simply transferring it to another repository should not revitalize the ticket. 

Usage Fees and Incentives Specification 

40 

[0108] The billing for use of a digital work is fundamental to a commercial distribution system. Grammar Element 
1517 "Fee-Spec: = {Scheduled-Dlscount} Regular-Fee-Spec I Scheduied-Fee-Spec i l\flarkup-Spec" provides a 
range of options for billing for the use of digital works. 

[0109] A key feature of this approach is the development of low-overhead billing for transactions in potentially small 
^5 amounts. Thus, it becomes feasible to collect fees of only a few cents each for thousands of transactions. 

[01 10] The grammar differentiates between uses where the charge is per use from those where it is metered by the 
time unit. Transactions can support fees that the user pays for using a digital woric as well as incentives paid by the 
right grantor to users to induce them to use or distribute the digital work. 

[01 1 1 ] The optional scheduled discount refers to the rest of the fee specification-discounting it by a percentage over 
50 time. If it is not specified, then there Is no scheduled discount. Regular fee specifbations are constant over time. 
Scheduled fee specifications give a schedule of dates over which the fee specifications change Markup specifications 
are used in d-blocks for adding a percentage to the fees already being charged. 

[0112] Grammar Element 1518 "Scheduled-Discount: = (Scheduled-Dlscount: (Time-Spec PercentageH" A 

Scheduled-Dlscount Is a essentially a scheduled modifier of any other fee specification for this version of the right of 
55 the digital work. (It does not refer to children or parent digital works or to other versions of rights.). It is a list of pairs 
of times and percentages. The most recent time in the list that has not yet passed at the time of the transaction is the 
one in effect. The percentage gives the discount percentage. For example, the number 10 refers to a 10% discount. 
[0113] Grammar Element 1519 "Reguiar-Fee-Spec : = ({Fee: I Incentive: } [Per-Use-Spec I IMetered-Rate-Spec 
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I Best-Price-Spec I Cail-For-Price-Spec ] {Min: Money-Unit Per: Time-Spec}{Max: Money-Unit Per: Time-Spec} 
To: Account-ID)** provides for several kinds of fee specifications. 

[0114] Fees are paid by the copy-owner/user to the revenue-owner if Fee: is specified. Incentives are paid by the 

revenue^owner to the user if Incentive: Is specified. If the Min: specification Is given, then there is a minimum fee to 
5 be charged pertlme-spec unit for Its use. If the Max: specification Is given, then there Is a maximum fee to be charged 

per time-spec for its use. When Fee: is specified, Account-iD identifies the account to which the fee is.to be paid. 

When Incentive: Is specified, Account-ID Identifies the account from which the fee is to be paid. 

[01 15] Grammar element 1520 "Per-Use-Spec: = Per-Use: Money-unit" defines a simple fee to be paid every time 

the right Is exercised, regardless of how much time the transaction takes. 
10 [0116] Grammar element 1521 "Metered-Rate-Spec : = Metered: Money-Unit Per: Time-Spec" defines a metered- 

ratefee paid according to how long the right is exercised. Thus, the time it takes to complete the transaction detemnines 

the fee. 

[01 17] Grammar element 1 522 "Best-Price-Spec : = Best-Price: Money-unit Max: Money-unit" Is used to specify 
a best-price that is detemnined when the account is settled. This specif rcation is to accommodate special deals, rebates, 

15 and pricing that depends on Information that Is not available to the repository. All fee specifications can be combined 
with tickets or authorizations that could indicate that the consumer is a wholesaler or that he Is a preferred customer, 
or that the seller be authorized in some way The amount of money in the Max: field is the maximum amount that the 
use will cost. This is the amount that is tentatively debited from the credit sen/er. However, when the transaction is 
ultimately reconciled, any excess amount will be returned to the consumer in a separate transaction. 

20 [0118] Grammar element 1623 "Cali-For-Price-Spec : = Call-For-Prlce " Is simllarto a "Best-Price-Spec" In that 
it is intended to accommodate cases where prices are dynamic. A Cali-For-Price Spec requires a communication with 
a dealer to detemnine the price. This option cannot be exercised if the repository cannot communicate with a dealer at 
the time that the right is exercised. It Is based on a secure transaction whereby the dealer names a price to exercise 
the right and passes along a deal certificate which Is referenced or included In the billing process. 

25 [0119] Grammar element 1524 "Scheduled-Fee-Spec: = (Schedule: (Time-Spec Reguiar-Fee-Spec)*)" Is used 
to provide a schedule of dates over which the fee specifications change. The fee specification with the most recent 
date not in the future is the one that Is In effect. This is similar to but more general than the scheduled discount. It is 
more general, because It provides a means to vary the fee agreement for each time period. 

[0120] Grammar element 1525 "Marlcup-Spec: = Marlcup: percentage To: Account-ID" is provided for adding a 
30 percentage to the fees already being charged. For example, a 5% markup means that a fee of 5% of cumulative fee 
so far will be allocated to the distributor. A markup specification can be applied to all of the other kinds of fee specifi- 
cations. It is typically used in a shell provided by a distributor. It refers to fees associated with d-blocks that are parts 
of the current d-block. This might be a convenient specification for use in taxes, or in distributor overhead. 

35 REPOSITORY TRANSACTIONS 

[0121] When a user requests access to a digital wort(, the repository will Initiate various transactions. The-combination 
of transactions invoked will depend on the specifications assigned for a usage right. There are three basic types of 
transactions, Session Initiation Transactions, Financial Transactions and Usage Transactions. Generally, session Inl- 

40 tiation transactions are Initiated first to establish a valid session. When a valid session Is established, transactions 
corresponding to the various usage rights are invoked. Finally, request specific transactions are perfomried. 
[0122] Transactions occur between two repositories (one acting as a server), between a repository and a document 
playback platform (e.g. for executing or viewing), between a repository and a credit server or between a repository and 
an authorization server. When transactions occur between more than one repository, It Is assumed that there is a 

45 reliable communication channel between the repositories. For example, this could be a TCP/IP channel or any other 
commercially available channel that has built-in capabilities for detecting and correcting transmission errors. However, 
It Is not assumed that the communication channel is secure Provisions for security and privacy are part of the require- 
ments for specifying and implementing repositories and thus fomn the need for various transactions. 

50 Message Transmission 

[0123] Transactions require that there be some communication between repositories. Communication between re- 
positories occurs in units tenned as messages. Because the communication line is assumed to be unsecure, all com- 
munications with repositories that are above the lowest security class are encrypted utilizing a public key encryption 
55 technique. Public key encryption is a well known technique In the encryption arts. The temi key refers to a numeric 
code that Is used with encryption and decryption algorithms. Keys come In pairs, where "writing keys" are used to 
encrypt data and "checking keys" are used to decrypt data. Both writing and checking keys may be public or private. 
Public keys are those that are distributed to others. Private keys are maintained in confidence. 
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[01 24] Key management and security is instrumental in the success of a public key encryption system. In the cun-ently 
preferred embodiment, one or more master repositories maintain the keys and create the identification certificates 
used by the repositories. 

[0125] When a sending repository transmits a message to a receiving repository, the sending repository encrypts all 
5 of Its data using the public writing key of the receiving repository. The sending repository Includes Its name, the name 
of the receiving repository, a session Identifier such as a nonce (described below), and a message counter In each 
message. 

[01 26] In this way, the communication can only be read (to a high probability) by the receiving repository, which holds 
the private checking key for decryption. The auxiliary data is used to guard against various replay attacks to security. 
10 [f messages ever arrive with the wrong counter or an old nonce, the repositories can assume that someone Is Interfering 
with communication and the transaction terminated. 

[01 27] The respective public keys for the repositories to be used for encryption are obtained in the registration trans- 
action described below. 

15 Session Initiation Transactions 

[0128] A usage transaction is carried out In a session between repositories. For usage transactions involving more 
than one repository, or for financial transactions between a repository and a credit server, a registration transaction is 
performed. A second transaction temried a login transaction, may also be needed to Initiate the session. The goal of 
20 the registration transaction is to establish a secure channel between two repositories who know each others identities. 
As it is assumed that the communication channel between the repositories Is reliable but not secure, there Is a risk 
that a non-repository may mimic the protocol in order to gain llleg'rtimate access to a repository. 
[0129] The registration transaction between two repositories is described with respect to Figures 16 and 17. The 
steps described are from the perspective of a "repository-1 " registering its Identity with a "repository-2". The registration 
25 must be symmetrical so the same set of steps will be repeated for repository-2 registering its identity with repository- 
1 . Referring to Figure 1 6, reposltory-1 first generates an encrypted registration Identifier, step 1 601 and then generates 
a registration message, step 1602. A registration message is comprised of an identifier of a master repository, the 
identification certificate for the repository-1 and an encrypted random registration identifier. The identification certificate 
Is encrypted by the master repository in Its private key and attests to the fact that the repository (here repository-1 ) Is 
30 a bona fide repository. The Identification certificate also contains a public key for the repository, the repository security 
level and a timestamp (indicating a time after which the certificate is no longer valid.) The registration identifier is a 
number generated by the repository for this registration. The registration identifier is unique to the session and Is 
encrypted in repository-1 's private key. The registration identifier is used to improve security of authentication by de- 
tecting certain kinds of communications based attacks. Repository-1 then transmits the registration message to repos- 
es itory-2, step 1603. 

[01 30] Upon receiving the registration message, repository-2 detemnines if it has the needed public key for the master 
repository, step 1 604. If repository-2 does not have the needed public key to decrypt the identification certificate, the 
registration transaction temninates in an error, step 1618. 

[0131] Assuming that repository-2 has the proper public key the identification certificate is decrypted, step 1605. 

40 Repository-2 saves the encrypted registration identifier, step 1606, and extracts the repository identifier, step 1607. 
The extracted repository identifier is checked against a "hotlist" of compromised document repositories, step 1608. In 
the currently prefen-ed embodiment, each repository will contain "hotlists" of compromised repositories, if the repository 
Is on the "hotlisf, the registration transaction temninates In an en^or per step 1 61 8 Repositories can be removed from 
the hotlist when their certificates expire, so that the list does not need to grow without bound. Also, by keeping a short 

45 list of hotiist certificates that It has previously received, a repository can avoid the wori< of actually going through the 
list. These lists would be encrypted by a master repository. A minor variation on the approach to Improve efficiency 
would have the repositories first exchange lists of names of hotlist certificates, ultimately exchanging only those lists 
that they had not previously received. The "hotlists" are maintained and distributed by Master repositories. 
[0132] Note that rather than tenninating in error, the transaction could request that another registration message be 

50 sent based on an Identification certificate created by another master repository. This may be repeated until a satisfactory 
identification certificate is found, or It is determined that trust cannot be established. 

[0133] Assuming that the repository is not on the hotlist, the repository identification needs to be verified. In other 
words, reposltory-2 needs to validate that the repository on the other end Is really reposltory-1 . This Is temied perfomn- 
ance testing and is perfomied in order to avoid invalid access to the repository via a counterfeit repository replaying a 
55 recording of a prior session initiation between repository-1 and repository-2. Performance testing is initiated by repos- 
ltory-2 generating a perfonnance message, step 1609. The perfomriance message consists of a nonce, the names of 
the respective repositories, the time and the registration identifier received from repository-1 . A nonce is a generated 
message based on some random and variable infomnation (e.g. the time or the temperature.) The nonce is used to 



16 



EP 0 715 247 B1 



check whether repository-1 can actually exhibit correct encrypting of a message using the private keys it claims to 
have, on a message that It has never seen before. The perfomnance message is encrypted using the public key specified 
in the registration message of reposrtory-1 . The perfonnance message is transmitted to repository-1 , step 1 61 0, where 
it is decrypted by reposrtory-1 using Its private key, step 1611. Reposltory-1 then checks to make sure that the names 

5 of the two repositories are correct, step 1612, that the time is accurate, step 1613 and that the registration identifier 
corresponds to the one It sent, step 1614. if any of these tests fails, the transaction Is terminated per step 1616. 
Assuming that the tests are passed, reposltory-1 transmits the nonce to reposltory-2 in the dear, step 1615. Reposltory- 
2 then compares the received nonce to the original nonce, step 1 61 7. If they are not Identical , the registration transaction 
temnlnates In an error per step 1 61 8. If they are the same, the registration transaction has successfully completed. 

10 [01 34] At this point, assuming that the transaction has not terminated, the repositories exchange messages contain- 
ing session keys to be used In all communications during the session and synchronize their clocks. Figure 1 7 illustrates 
the session infomriation exchange and clock synchronization steps (again from the perspective of reposltory-l.) Re- 
ferring to Figure 17, reposltory-1 creates a session key pair, step 1701. A first key Is kept private and is used by 
repository<1 to encrypt messages. The second key is a public key used by repository-2 to decrypt messages. The 

15 second key Is encrypted using the public key of reposltory-2, step 1702 and Is sent to reposftory-2, step 1703. Upon 
receipt, repository-2 decrypts the second key, step 1704. The second key Is used to decrypt messages in subsequent 
communications. When each repository has completed this step, they are both convinced that the other repository Is 
bona fide and that they are communicating with the original. Each repository has given the other a key to be used In 
decrypting further communications during the session. Since that key is itself transmitted in the public key of the re- 

20 celving repository only it will be able to decrypt the key which Is used to decrypt subsequent messages. 

[0135] After the session infonmation is exchanged, the repositories must synchronize their clocks Clock synchroni- 
zation is used by the repositories to establish an agreed upon time base for the financial records of their mutual trans- 
actions. Referring back to Figure 1 7, repository-2 Initiates clock synchronization by generating a time stamp exchange 
message, step 1705, and transmits it to repository-1, step 1706 Upon receipt, repository-1 generates Its own time 

25 stamp message, step 1 707 and transmits it back to repository-2, step 1 708 Reposltory-2 notes the current time, step 
1709 and stores the time received from repository-1, step 1710. The current time Is compared to the time received 
from reposltory-1 , step 1711 . The difference is then checked to see if it exceeds a predetennined tolerance (e.g. one 
minute), step 1 71 2. If it does, repository-2 tennlnates the transaction as this may Indicate tampering with the repository, 
step 1713. If not repository-2 computes an adjusted time delta, step 1714. The adjusted time delta is the difference 

30 between the clock time of reposltory-2 and the average of the times from repository-1 and repository-2. 

[0136] To achieve greater accuracy, repository-2 can request the time again up to a fixed number of times (e.g. five 
times), repeat the clock synchronization steps, and average the results. 

[0137] A second session initiation transaction Is a Login transaction. The Login transaction Is used to check the 
authenticity of a user requesting a transaction . A Login transaction Is particularly prudentfor the authorization of financial 

35 transactions that will be charged to a credit server. The Login transaction Involves an Interaction between the user at 
a user interface and the credit server associated with a repository. The Infomriation exchanged here Is a login string 
supplied by the repository/credit server to Identify itself to the user, and a Personal identification Number (PIN) provided 
by the user to identify himself to the credit server. In the event that the user is accessing a credit server on a repository 
different from the one on which the user interface resides, exchange of the information would be encrypted using the 

40 public and private keys of the respective repositories. 

Billing Transactions 

[0138] Billing Transactions are concerned with monetary transactions with a credit server. Billing Transactions are 
45 earned out when all other conditions are satisfied and a usage fee is required for granting the request. For the most 
part, billing transactions are well understood in the state of the art. These transactions are between a repository and 
a credit server, or between a credit server and a billing clearinghouse. Briefly, the required transactions include the 
following: 

50 • Registration and LOGIN transactions by which the repository and user establish their bona fides to a credit server. 

These transactions would be entirely internal in cases where the repository and credit server are Implemented as 
a single system. 

• Registration and LOGIN transactions, by which a credit sender establishes its bona fides to a billing clearinghouse. 

• An Assign-fee transaction to assign a charge. The infomriation in this transaction would Include a transaction iden- 
55 tifler, the identities of the repositories in the transaction, and a list of charges from the parts of the digital woric. If 

there has been any unusual event in the transaction such as an interruption of communications, that infomriation 
is Included as well. 

• A Begin-charges transaction to assign a charge. This transaction Is much the same as an assign-fee transaction 
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except that it is used for metered use. It includes the same information as the assign-fee transaction as well as 
the usage fee infomriation. The credit-server Is then responsible for running a clock. 
• An End-charges transaction to end a charge for metered use. (In a variation on this approach, the repositories 
would exchange periodic charge infomnatlon for each block of time.) 
5 • A report-charges transaction between a personal credit server and a billing clearinghouse. This transaction is 
Invoked at least once per billing period. It is used to pass along Infonmation about charges. On debit and credit 
cards, this transaction would also be used to update balance infonmation and credit limits as needed. 

[0139] All billing transactions are given a transaction ID and are reported to the credit severs by both the server and 
10 the client. This reduces possible loss of billing infomnatlon if one of the parties to a transaction loses a banking card 
and provides a check against tampering with the system. 

Usage Transactions 

15 [0140] After the session initiation transactions have been completed, the usage request may then be processed. To 
simplify the description of the steps carried out in processing a usage request, the tenn requester is used to refer to a 
repository in the requester mode which is initiating a request, and the temi server is used to refer to a repository in the 
server mode and which contains the desired digital work. In many cases such as requests to print or view a work, the 
requester and server may be the same device and the transactions described In the following would be entirely internal. 

20 In such instances, certain transaction steps, such as the registration transaction, need not be perfomned. 

[0141] There are some common steps that are part of the semantics of all of the usage rights transactions. These 
steps are referred to as the common transaction steps. There are two sets ~ the "opening" steps and the "closing" 
steps. For simplicity, these are listed here rather than repeating them in the descriptions of all of the usage rights 
transactions. 

25 [0142] Transactions can refer to a part of a digital work, a complete digital wori<, or a Digital work containing other 
digital works. Although not described in detail herein, a transaction may even refer to a folder comprised of a plurality 
of digital wort<s. The term "work" is used to refer to what ever portion or set of digital works Is being accessed. 
[0143] Many of the steps here involve determining if certain conditions are satisfied. Recall that each usage right 
may have one or more conditions which must be satisfied before the right can be exercised. Digital works have parts 

30 and parts have parts. Different parts can have different rights and fees Thus, It Is necessary to verify that the require- 
ments are met for ALL of the parts that are involved in a transaction For brevity, when reference Is made to checking 
whether the rights exist and conditions for exercising are satisfied, it is meant that all such checking takes place for 
each of the relevant parts of the woric. 

[0144] Figure 18 illustrates the initial common opening and closing steps for a transaction. At this point it is assumed 

35 that registration has occurred and that a "trusted" session is In place. General tests are tests on usage rights associated 
with the folder containing the work or some containing folder higher in the file system hierarchy. These tests con-espond 
to requirements imposed on the woric as a consequence of its being on the particular repository, as opposed to being 
attached to the wortc itself. Refen^lng to Figure 18, prior to Initiating a usage transaction, the requester perfomns any 
general tests that are required before the right associated with the transaction can be exercised, step, 1 801 . For ex- 

40 ample, install, uninstall and delete rights may be implemented to require that a requester have an authorization certif- 
icate before the right can be exercised. Another example is the requirement that a digital ticket be present and punched 
before a digital work may be copied to a requester. If any of the general tests fail, the transaction is not initiated, step, 
1802. Assuming that such required tests are passed, upon receiving the usage request, the server generates a trans- 
action identifier that is used in records or reports of the transaction, step 1 803. The server then checks whether the 

45 digital work has been granted the right corresponding to the requested transaction, step 1 804. If the digital work has 
not been granted the right conresponding to the request, the transaction temrilnates, step 1805. If the digital work has 
been granted the requested right, the server then detemnines If the various conditions for exercising the right are 
satisfied. Time based conditions are examined, step 1 806. These conditions are checked by examining the time spec- 
ification for the the version of the right. If any of the conditions are not satisfied, the transaction tenninates per step 1 805. 

50 [01 45] Assuming that the time based conditions are satisfied, the server checks security and access conditions, step 
1 807. Such security and access conditions are satisfied if: 1 ) the requester Is at the specified security class, or a higher 
security class, 2) the server satisfies any specified authorization test and 3) the requester satisfies any specified au- 
thorization tests and has any required digital tickets. If any of the conditions are not satisfied, the transaction tenninates 
per step 1805. 

55 [0146] Assuming that the security and access conditions are all satisfied, the server checks the copy count condition, 
step 1 808 If the copy count equals zero, then the transaction cannot be completed and the transaction tenninates per 
step 1805. 

[0147] Assuming that the copy count does not equal zero, the server checks if the copies in use for the requested 
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right is greater than or equal to any copy count for the requested right (or relevant parts), step 1809. If the copies in 
use is greater than or equal to the copy count, this indicates that usage rights for the version of the transaction have 
been exhausted. Accordingly, the server terminates the transaction, step 1 805. If the copy count is less than the copies 
in use for the transaction the transaction can continue, and the copies in use would be incrennented by the number of 

5 digital worics requested in the transaction, step 1 81 0. 

[0148] The server then checks If the digital woric has a "Loan" access right, step 1811 . The "Loan" access right is a 
special case since remaining rights may be present even though all copies are loaned out. If the digital work has the 
"Loan" access right, a check is made to see if all copies have been loaned out, step 1812. The number of copies that 
could be loaned is the sum of the Copy-Counts for all of the versions of the loan right of the digital wori<. For a composite 

10 woric, the relevant figure is the minimal such sum of each of the components of the composite work. If all copies have 
been loaned out, the remaining rights aredetemnined, step 1813. Theremaining-rights is detemnined from the remaining 
rights specifications from the versions of the Loan right. If there is only one version of the Loan right, then the deter- 
mination is simple. The remaining rights are the ones specified in that version of the Loan right, or none if Remaining- 
Rights: is not specified. If there are multiple versions of the Loan right and all copies of all of the versions are loaned 

15 out, then the remaining rights is taken as the minimum set (intersection) of remaining rights across all of the versions 
of the loan right. The server then determines if the requested right is in the set of remaining rights, step 1814. If the 
requested right is not in the set of remaining rights, the server terminates the transaction, step 1805. 
[0149] If Loan Is not a usage right for the digital work or if all copies have not been loaned out or the requested right 
is in the set of remaining rights, fee conditions forthe right are then checked, step 1815. This will initiate various financial 

20 transactions between the repository and associated credit server. Further, any metering of usage of a digital work will 
commence. If any financial transaction fails, the transaction tenminates per step 1805. 

[0150] It should be noted that the order in which the conditions are checked need not follow the order of steps 
1806-1815. 

[0151] At this point, right specific steps are now performed and are represented here as step 1 81 6. The right specific 

25 steps are described in greater detail below. 

[0152] The common closing transaction steps are now perfonned. Each of the closing transaction steps are per- 
fonried by the server after a successful completion of a transaction. Referring back to Figure 18, the copies in use 
value for the requested right is decremented by the number of copies involved in the transaction, step 1 81 7. Next, if 
the right had a metered usage fee specification, the sender subtracts the elapsed time from the Remaining-Use-Tlme 

30 associated with the right for every part involved in the transaction, step 1818. Finally, if there are fee specifications 
associated with the right, the server Initiates End-Charge financial transaction to conflmn billing, step 1 81 9. 

Transmission Protocol 

35 [0153] An Important area to consider is the transmission of the digital woric from the server to the requester. The 
transmission protocol described herein refers to events occurring after a valid session has been created. The trans- 
mission protocol must handle the case of disruption in the communications between the repositories. It is assumed 
that interference such as Injecting noise on the communication channel can be detected by the integrity checks (e.g., 
parity, checksum, etc.) that are built into the transport protocol and are not discussed in detail herein. 

40 [0154] The underlying goal in the transmission protocol is to preclude certain failure modes, such as malicious or 
accidental interference on the communications channel. Suppose, for example, that a user putts a card with the credit 
server at a specific time near the end of a transaction. There should not be a vulnerable time at which "pulling the card" 
causes th e repositories to fail to con-ectly account for the number of copies of the woric that have been created. Restated, 
there should be no time at which a party can break a connection as a means to avoid payment after using a digital work. 
[01 55] If a transaction is inten'upted (and fails), both repositories restore the digital works and accounts to their state 
prior to the failure, modulo records of the failure Itself. 

[0156] Figure 19 is a state diagram showing steps in the process of transmitting infomiation during a transaction. 
Each box represents a state of a repository in either the server mode (above the central dotted line 1901 ) or in the 
requester mode (below the dotted line 1 901 ). Solid an^ows stand for transitions between states. Dashed arrows stand 

50 for message communications between the repositories. A dashed message arrow pointing to a solid transition arrow 
is interpreted as meaning that the transition takes place when the message Is received Unlabeled transition arrows 
take place unconditionally. Other labels on state transition arrows describe conditions that trigger the transition. 
[0157] Referring now to Figure 19, the server is initially in a state 1902 where a new transaction is initiated via start 
message 1903. This message includes transaction infomiation Including a transaction identifier and a count of the 

55 blocks of data to be transferred. The requester, initially in a wait state 1 904 then enters a data wait state 1 905. 

[0158] The server enters a data transmit state 1906 and transmits a block of data 1907 and then enters a wait for 
acknowledgement state 1908. As the data is received, the requester enters a data receive state 1909 and when the 
data blocks are completely received it enters an acknowledgement state 1910 and transmits an Acknowledgement 



19 



EP 0 715 247 B1 



message 1911 to the server. 

[0159] If there are more blocks to send, the server waits until receiving an Acknowledgement message from the 
requester When an Acknowledgement message is received it sends the next block to the requester and again waits 
for acknowledgement. The requester also repeats the same cycle of states. 
5 [01 60] If the server detects a communications failure before sending the last block, it enters a cancellation state 1912 
wherein the transaction is cancelled. Similarly, if the requester detects a communications failure before receiving the 
last block It enters a cancellation state 1913. 

[0161] If there are no more blocks to send, the server commits to the transaction and waits for the final Acknowl- 
edgement in state 1914. If there is a communications failure before the server receives the final Acknowledgement 
10 message, it still commits to the transaction but includes a report about the event to its credit server in state 1915. This 
report serves two purposes It will help legitimize any claims by a user of having been billed for receiving digital works 
that were not completely received. Also it helps to identify repositories and communications lines that have suspicious 
patterns of use and Interruption. The server then enters its completion state 1916 

[0162] On the requester side, when there are no more blocks to receive, the requester commits to the transaction 
15 in state 1 91 7. If the requester detects a communications failure at this state, it reports the failure to Its credit server in 
state 1 91 8, but still commits to the transaction. When it has committed, it sends an acknowledgement message to the 
server. The server then enters its completion state 1919. 

[01 63] The key property is that both the server and the requester cancel a transaction if it is inten-upted before all of 
the data blocks are delivered, and commits to it if all of the data blocks have been delivered. 

20 [0164] There is a possibility that the server will have sent all of the data blocks (and committed) but the requester 
will not have received all of them and will cancel the transaction. In this case, both repositories will presumably detect 
a communications failure and report it to their credit server. This case will probably be rare since it depends on very 
precise timing of the communications failure. The only consequence will be that the user at the requester repository 
may want to request a refund from the credit services - and the case for that refund will be documented by reports by 

25 both repositories. 

[0165] To prevent loss of data, the server should not delete any transferred digital work until receiving the final ac- 
knowledgement from the requester. But It also should not use the file. A well known way to deal with this situation is 
called "two-phase commit" or 2PC. 

[0166] Two-phase commit works as follows. The first phase works the same as the method described above. The 
30 server sends all of the data to the requester. Both repositories mark the transaction (and appropriate files) as uncom- 
mitted. The server sends a ready-to-commit message to the requester. The requester sends back an acknowledgement. 
The server then commits and sends the requester a commit message. When the requester receives the commit mes- 
sage, it commits the file. 

[01 67] If there is a communication failure or other crash, the requester must check back with the server to determine 
35 the status of the transaction. The server has the last word on this. The requester may have received all of the data, 
but if it did not get the final message, it has not committed. The server can go ahead and delete files (except for 
transaction records) once it commits, since the files are known to have been fully transmitted before starting the 2PC 
cycle. 

[0168] There are variations known In the art which can be used to achieve the same effect. For example, the server 
40 could use an additional level of encryption when transmitting a work to a client. Only after the client sends a message 
acknowledging receipt does it send the key. The client then agrees to pay for the digital work. The point of this variation 
is that it provides a clear audit trail that the client received the wortc. For trusted systems, however, this variation adds 
a level of encryption for no real gain in accountability. 
[0169] The transaction for specif usage rights are now discussed. 

45 

The Copy TVansactlon 

[01 70] A Copy transaction is a request to make one or more independent copies of the work with the same or lesser 
usage rights. Copy differs from the extraction right discussed later in that it refers to entire digital works or entire folders 
50 containing digital works. A copy operation cannot be used to remove a portion of a digital wori<. 

• The requester sends the server a message to initiate the Copy Transaction. This message Indicates the wort< to 
be copied, the version of the copy right to be used for the transaction, the destination address Information (location 
in a folder) for placing the work, the file data for the work (Including its size), and the number of copies requested. 

55 • The repositories perfomn the common opening transaction steps. 

• The server transmits the requested contents and data to the client according to the transmission protocol. If a 
Next-Set-Of-Rlghts has been provided In the version of the right, those rights are transmitted as the rights for the 
work. Otherwise, the rights of the original are transmitted. In any event, the Copy-Count field for the copy of the 
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digital work being sent right is set to the number-of-copies requested. 

• The requester records the work contents, data, and usage rights and stores the work. It records the date and tinne 
that the copy was made in the properties of the digital work. 

• The repositories perform the common closing transaction steps. 

5 

The Transfer Transaction 

[01 71 ] A Transfer transaction Is a request to move copies of the work with the same or lesser usage rights to another 
repository. In contrast with a copy transaction, this results In removing the work copies from the server. 

10 

• The requester sends the server a message to initiate the Transfer Transaction. This message indicates the work 
to be transferred, the version of the transfer right to be used in the transaction, the destination address Information 
for placing the work, the file data for the work, and the number of copies involved. 

• The repositories perfomi the common opening transaction steps. 

15 • The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the work. Otherwise, the 
rights of the original are transmitted. In either case, the Copy-Count field for the transmitted rights are set to the 
number-of-copies requested. 

• The requester records the woric contents, data, and usage rights and stores the woric. 

20 • The server decrements Its copy count by the number of copies Involved In the transaction. 

• The repositories perform the common closing transaction steps. 

• If the number of copies remaining in the server is now zero. It erases the digital work from its memory. 
The Loan Transaction 

25 

[0172] A loan transaction is a mechanism for loaning copies of a digital work. The maximum duration of the loan is 
detemnined by an Internal parameter of the digital woric. Works are automatically returned after a predetemilned time 
period. 

30 • The requester sends the server a message to initiate the Transfer Transaction. This message indicates the wori< 
to be loaned, the version of the loan right to be used In the transaction, the destination address Infomriatlon for 
placing the work, the number of copies Involved, the file data for the work, and the period of the loan. 

• The server checks the validity of the requested loan period, and ends with an error If the period is not valid. Loans 
for a loaned copy cannot extend beyond the period of the original loan to the server. 

35 • The repositories perform the common opening transaction steps. 

• The server transmits the requested contents and data to the requester. If a Next-Set-Of-Rlghts has been provided, 
those rights are transmitted as the rights for the work. Othenwise, the rights of the original are transmitted, as 
modified to reflect the loan period. 

• The requester records the digital wori< contents, data, usage rights, and. loan period and stores the work. 

40 • The server updates the usage rights infomriation In the digital wori< to reflect the number of copies loaned out. 

• The repositories perfomi the common closing transaction steps. 

• The server updates the usage rights data for the digital work. This may preclude use of the work until it is returned 
from the loan. The user on the requester platfomi can now use the transferred copies of the digital work. A user 
accessing the original repository cannot use the digital work , unless there are copies remaining. What happens 

45 next depends on the order of events in time. 

Case 1 . If the time of the loan period is not yet exhausted and the requester sends the repository a Return 
message. 

50 • The return message Includes the requester identification, and the transaction ID. 

• The server decrements the coples-in-use field by the number of copies that were returned (If the number 
of digital works returned Is greater than the number actually borrowed, this is treated as an error.) This 
step may now make the work available at the sender for other users. 

• The requester deactivates Its copies and removes the contents from Its memory. 

55 

Case 2 If the time of the loan period is exhausted and the requester has not yet sent a Return message 

• The sen/er decrements the coples-in-use field by the number digital worics that were borrowed. 
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• The requester automatically deactivates its copies of the digital work. It terminates all current uses and 
erases the digital work copies from memory. One question is why a requester would ever return a work 
earlier than the period of the loan, since it would be returned automatically anyway. One reason for early 
return is that there may be a metered fee which detemfiines the cost of the loan. Retuming early may 
5 reduce that fee. 

The Play TVansaction 

[0173] A play transaction Is a request to use the contents of a work. Typically, to "play" a work is to send the digital 
10 work through some kind of transducer, such as a speaker or a display device. The request implies the intention that 
the contents will not be communicated digitally to any other system. For example, they will not be sent to a printer, 
recorded on any digital medium, retained after the transaction or sent to another repository. 
[0174] This term "play" is natural for examples like playing music, playing a movie, or playing a video game. The 
general fonn of play means that a "player" is used to use the digital work. However, the terni play covers all media and 
15 kinds of recordings. Thus one would "play" a digital work, meaning, to render it for reading, or play a computer program, 
meaning to execute it. For a digital ticket the player would be a digital ticket agent. 

• The requester sends the server a message to initiate the play transaction. This message indicates the work to be 
played, the version of the play right to be used in the transaction, the identity of the player being used, and the file 

20 data for the work. 

• The server checks the validity of the player identification and the compatibility of the player Identification with the 
player specification in the right. It ends with an error if these are not satisfactory. 

• The repositories perform the common opening transaction steps. 

• The server and requester read and write the blocks of data as requested by the player according to the transmission 
25 protocol. The requester plays the work contents, using the player. 

• When the player is finished, the player and the requester remove the contents from their memory. 

• The repositories perfomn the common closing transaction steps. 

The Print Transaction 

30 

[0175] A Print transaction Is a request to obtain the contents of a work for the purpose of rendering them on a "printer." 
We use the term "printer" to include the common case of writing with ink on paper. However, the key aspect of "printing" 
in our use of the terni Is that It makes a copy of the digital work in a place outside of the protection of usage rights. As 
with all rights, this may require particular authorization certificates. 

35 [0176] Once a digital wori< is printed, the publisher and user are bound by whatever copyright laws are in effect 
However, printing moves the contents outside the control of repositories. For example, absent any other enforcement 
mechanisms, once a digital wort< is printed on paper, it can be copied on ordinary photocopying machines without 
intervention by a repository to collect usage fees. If the printer to a digital disk is pemiitted, then that digital copy is 
outside of the control of usage rights. Both the creator and the user know this, although the creator does not necessarily 

40 give tacit consent to such copying, which may violate copyright laws. 

• The requester sends the server a message to initiate a Print transaction. This message indicates the work to be 
played, the identity of the printer being used, the file data for the wortc, and the number of copies in the request. 

• The server checks the validity of the printer identification and the compatibility of the printer identification with the 
45 printer specification in the right. It ends with an en-or if these are not satisfactory. 

• The repositories perfomn the common opening transaction steps. 

• The server transmits blocks of data according to the transmission protocol. 

• The requester prints the work contents, using the printer. 

• When the printer is finished, the printer and the requester remove the contents from their memory. 
50 • The repositories perionn the common closing transaction steps. 

The Backup Transaction 

[0177] A Backup transaction is a request to make a backup copy of a digital wori<, as a protection against media 
55 failure. In the context of repositories, secure backup copies differ from other copies in three ways: (1 ) they are made 
under the control of a Backup transaction rather than a Copy transaction, (2) they do not count as regular copies, and 
(3) they are not usable as regular copies. Generally, backup copies are encrypted. 

[0178] Although backup copies may be transfen^ed or copied, depending on their assigned rights, the only way to 
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make them useful for playing, printing or embedding is to restore them. 

[0179] The output of a Backup operation Is both an encrypted data file that contains the contents and description of 
a work, and a restoration file with an encryption key for restoring the encrypted contents. In many cases, the encrypted 
data file would have rights for "printing" It to a disk outside of the protection system, relying just on its encryption for 
5 security. Such files could be stored anywhere that was physically safe and convenient. The restoration file would be 
held in the repository This file Is necessary for the restoration of a backup copy, it may have rights for transfer between 
repositories. 

• The requester sends the server a message to initiate a backup transaction. This message indicates the work to 
10 be backed up, the version of the backup right to be used in the transaction, the destination address information 

for placing the backup copy, the file data for the work. 

• The repositories perfomn the common opening transaction steps. 

• The server transmits the requested contents and data to the requester. If a Next-Set-Of-Rlghts has been provided, 
those rights are transmitted as the rights for the work. Otherwise, a set of default rights for backup files of the 

IS original are transmitted by the server 

• The requester records the work contents, data, and usage rights. It then creates a one-time key and encrypts the 
contents file. It saves the key infonnation in a restoration file. 

• The repositories perfomn the common closing transaction steps. 

20 [01 80] In some cases, it Is convenient to be able to archive the large, encrypted contents fite to secure offline storage, 
such as a magneto-optical storage system or magnetic tape. This creation of a non-repository archive file is as secure 
as the encryption process. Such non-repository archive storage Is considered a form of "printing" and is controlled by 
a print right with a specified "archive-printer." An archive-printer device is programmed to save the encrypted contents 
file (but not the description file) offline in such a way that It can be retrieved. 

25 

The Restore Transaction 

[0181] A Restore transaction is a request to convert an encrypted backup copy of a digital work into a usable copy. 
A restore operation is intended to be used to compensate for catastrophic media f ail ure. Like all usage rights, restoration 
30 rights can include fees and access tests Including authorization checks. 

• The requester sends the server a message to initiate a Restore transaction. This message indicates the woric to 
be restored, the version of the restore right for the transaction, the destination address infonnation for placing the 
work, and the file data for the work. 

35 • The server verifies that the contents file Is available (I.e. a digital work corresponding to the request has been 
backed-up.) If it is not, It ends the transaction with an error. 

• The repositories perfomn the common opening transaction steps. 

• The server retrieves the key from the restoration file. It decrypts the work contents, data, and usage rights. 

• The server transmits the requested contents and data to the requester according to the transmission protocol. If 
40 a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the work. Otherwise, a set 

of default rights for backup files of the original are transmitted by the server. 

• The requester stores the digital work. 

• The repositories periomn the common closing transaction steps. 

45 The Delete Transaction 

[01 82] A Delete transaction deletes a digital work or a number of copies of a digital work from a repository. Practically 
all digital works would have delete rights. 

50 • The requester sends the server a message to Initiate a delete transaction. This message indicates the work to be 
deleted , the version of the delete right for the transaction. 

• The repositories perfomn the common opening transaction steps. 

• The server deletes the file, erasing It from the file system. 

• The repositories perfomn the common closing transaction steps. 

55 

The Directory Transaction 

[01 83] A Directory transaction is a request for infomnation about folders, digital works, and their parts. This amounts 
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to roughly the same idea as protection codes in a conventional file system like TENEX, except that it Is generalized to 
the full power of the access specifications of the usage rights language. 

[01 84] The Directory transaction has the important role of passing along descriptions of the rights and fees associated 

with a digital work. When a user wants to exercise a right, the user interface of his repository Implicftly makes a directory 
5 request to detemiine the versions of the right that are available. Typically these are presented to the user - such as 
with different choices of billing for exercising a right. Thus, many directory transactions are invisible to the user and 
are exercised as part of the nomnal process of exercising all rights. 

• The requester sends the server a message to initiate a Directory transaction. This message indicates the file or 
10 folder that is the root of the directory request and the version of the directory right used for the transaction. 

• The server verifies that the infonnation is accessible to the requester. In particular, It does not return the names 
of any files that have a HIDE-NAME status in their directory specifications, and it does not return the parts of any 
folders or files that have HIDE-PARTS In their specification. If the infomnatlon Is not accessible, the server ends 
the transaction with an en^or. 

IS • The repositories perform the common opening transaction steps. 

• The server sends the requested data to the requester according to the transmission protocol. 

• The requester records the data. 

• The repositories perform the common closing transaction steps. 

20 The Folder Transaction 

[0185] A Folder transaction is a request to create or rename a folder, or to move a wori< between folders. Together 
with Directory rights, Folder rights control the degree to which organization of a repository can be accessed or modified 
from another repository. 

25 

• The requester sends the server a message to initiate a Folder transaction. This message indicates the folder that 
Is the root of the folder request, the version of the folder right for the transaction, an operation, and data. The 
operation can be one of create, rename, and move file. The data are the specifications required for the operation, 
such as a specification of a folder or digital work and a name. 

30 • The repositories perfomn the common opening transaction steps. 

• The server perfomns the requested operation - creating a folder, renaming a folder, or moving a work between 
folders. 

• The repositories perform the common closing transaction steps. 

35 The Extract TVanaactlon 

[0186] A extract transaction is a request to copy a part of a digital woric and to create a new work containing It. The 
extraction operation differs from copying In that it can be used to separate a part of a digital work from d-blocks or 
shells that place additional restrictions or fees on it. The extraction operation differs from the edit operation in that It 
40 does not change the contents of a work, only its embedding in d-blocks. Extraction creates a new digital work. 

• The requester sends the server a message to Initiate an Extract transaction. This message Indicates the part of 
the wori< to be extracted, the version of the extract right to be used In the transaction, the destination address 
infonnation for placing the part as a new wori<, the file data for the woric, and the number of copies involved. 

45 • The repositories perfomn the common opening transaction steps. 

• The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the new work. Otherwise, 
the rights of the original are transmitted. The Copy-Count field forthls right Is setto the number-of-coples requested. 

• The requester records the contents, data, and usage rights and stores the woric. It records the date and time that 
50 new work was made In the properties of the work. 

• The repositories perfomn the common closing transaction steps. 

The Embed Transaction 

55 [0187] An embed transaction is a request to make a digital woric become a part of another digital work or to add a 
shell d-block to enable the adding of fees by a distributor of the work. 

• The requester sends the server a message to Initiate an Embed transaction. This message Indicates the work to 
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be embedded, the version of the embed right to be used in the transaction, the destination address infonnation 
for placing the part as a a work, the file data for the work, and the number of copies Involved. 

• The server checks the control specifications for all of the rights In the part and the destination. If they are incom- 
patible, the server ends the transaction with an error. 

5 » The repositories perform the common opening transaction steps. 

• The server transmits the requested contents and data to the requester according to the transmission protocol. If 
a Next-Set-Of-Rights has been provided, those rights are transmitted as the rights for the new work. Otherwise, 
the rights of the original are transmitted. The Copy-Count field forthis right is set to the number-of-coples requested. 

• The requester records the contents, data, and usage rights and embeds the work in the destination file. 
10 • The repositories perfomi the common closing transaction steps. 

The Edit Transaction 

[0188] An Edit transaction is a request to make a new digital woric by copying, selecting and modifying portions of 
15 an existing digital work. This operation can actually change the contents of a digital wori< The kinds of changes that 
are pennitted depend on the process being used. Like the extraction operation, edit operates on portions of a digital 
wori<. In contrast with the extract operation, edit does not affect the rights or location of the woric. It only changes the 
contents. The kinds of changes pennitted are detennlned by the type specification of the processor specified in the 
rights. In the cuaently pretended embodiment, an edit transaction changes the woric itself and does not make a new 
20 wortc. However, It would be a reasonable variation to cause a new copy of the woric to be made. 

• The requester sends the server a message to initiate an Edit transaction. This message Indicates the work to be 
edited, the version of the edit right to be used in the transaction, the file data for the work (Including Its size), the 
process-ID for the process, and the number of copies involved. 

25 • The server checks the compatibility of the process-iD to be used by the requester against any process-ID speci- 
fication in the right. If they are incompatible, it ends the transaction with an error. 

• The repositories perfomi the common opening transaction steps. 

• The requester uses the process to change the contents of the digital work as desired. (For example, it can select 
and duplicate parts of it; combine it with other infonnatlon; or compute functions based on the infonnation. This 

30 can amount to editing text, musk:, or pictures or taking whatever other steps are useful in creating a derivative work.) 

• The repositories perfomn the common closing transaction steps. 

[0189] The edit transaction is used to cover a wide range of kinds of works. The category describes a process that 
takes as Its input any portion of a digital work and then modifies the input in some way. For example, for text, a process 
35 for editing the text would require edit rights. A process for "summarizing" or counting words in the text would also be 
considered editing. For a music file, processing could involve changing the pitch or tempo, or adding reverberations, 
or any other audio effect. For digital video worics, anything which alters the Image would require edit rights. Examples 
would be colorizing, scaling, extracting still photos, selecting and combining frames Into story boards, sharpening with 
signal processing, and so on. 

40 [0190] Some creators may want to protect the authenticity of their works by limiting the kinds of processes that can 
be performed on them. If there are no edit rights, then no processing is allowed at all. A processor Identifier can be 
included to specify what kind of process is allowed If no process identifier Is specified, then ariDitrary processors can 
be used. For an example of a specif k; process, a photographer may want to allow use of his photograph but may not 
want It to be colorized. A musician may want to allow extraction of portions of his wori< but not changing of the tonality. 

45 

Authorization TVansactlons 

[0191] There are many ways that authorization transactions can be defined. In the following, our preferred way is to 
simply define them in temis of other transactions that we already need for repositories. Thus, It is convenient sometimes 
50 to speak of "authorization transactions," but they are actually made up of other transactions that repositories already 
have. 

[0192] A usage right can specify an authorization-ID, which identifies an authorization object (a digital work in a file 
of a standard fomriat) that the repository must have and which It must process. The authorization is given to the generic 
authorization (or ticket) server of the repository which begins to interpret the authorization. 
55 [01 93] As described eariier, the authorization contains a server identifier, which may just be the generic authorization 
server or it may be another server. When a remote authorization server is required, it must contain a digital address. 
It may also contain a digital certificate. 

[0194] If a remote authorization server is required, then the authorization process first perfomis the following steps: 
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• The generic authorization server attempts to set up the communications channel. (If the channel cannot be set 
up, then authorization fails with an error.) 

• When the channel is set up, It perfomis a registration process with the remote repository. (If registration fails, then 
the authorization falls with an error.) 

5 • When registration is complete, the generic authorization server invokes a "Play" transaction with the remote re> 
pository, supplying the authorization document as the digital wori< to be played, and the remote authorization server 
(a program) as the ''player" (If the player cannot be found or has some other error, then the authorization fails with 
an error.) 

• The authorization server then "plays" the authorization. This involves decrypting it using either the public key of 
10 the master repository that issued the certificate or the session key from the repository that transmitted it. The 

authorization server then perfomis various tests. These tests vary according to the authorization server. They 
include such steps as checking issue and validity dates of the authorization and checking any hot-lists of known 
invalid authorizations. The authorization server may require carrying out any other transactions on the repository 
as well, such as checking directories, getting some person to supply a password, or playing some other digital 
15 work. It may also invoke some special process for checking information about locations or recent events. The 

"script" for such steps is contained within the authorization server. 

• If all of the required steps are completed satisfactorily, the authorization server completes the transaction nonmally, 
signaling that authorization is granted. 

20 The Install Transaction 

[0195] An Install transaction is a request to Install a digital woric as ninnable software on a repository. In a typical 
case, the requester repository is a rendering repository and the software would be a new kind or new version of a 
player. Also in a typical case, the software would be copied to file system of the requester repository before it is installed. 

25 

• The requester sends the server an Install message. This message indicates the work to be installed, the version 
of the Install right being invoked, and the file data for the wori< (including its size). 

• The repositories perform the common opening transaction steps. 

• The requester extracts a copy of the digital certificate for the software. If the certificate cannot be found or the 
30 master repository for the certificate is not known to the requester, the transaction ends with an error. 

• The requester decrypts the digital certificate using the public key of the master repository, recording the identity 
of the supplier and creator, a key for decrypting the software, the compatibility information, and a tamper-checking 
code. (This step certifies the software.) 

• The requester decrypts the software using the key from the certificate and computes a check code on it using a 
35 1 -way hash function If the check-code does not match the tamper-checking code from the certificate, the Installation 

transaction ends with an error. (This step assures that the contents of the software, including the various scripts, 
have not been tampered with.) 

• The requester retrieves the instructions In the compatibility-checking script and follows them. If the software is not 
compatible with the repository, the installation transaction ends with an error. (This step checks platfomn compat- 

40 ibility.) 

• The requester retrieves the instructions in the installation script and follows them. If there is an error in this process 
(such as insufficient resources), then the transaction ends with an error. Note that the installation process puts the 
runnable software in a place in the repository where it is no longer accessible as a woric for exercising any usage 
rights other than the execution of the software as part of repository operations in carrying out other transactions. 

45 • The repositories perfomn the common closing transaction steps. 

The Uninstall Th'ansactlon 

[0196] An Uninstall transaction Is a request to remove software from a repository. Since uncontrolled or Incorrect 
50 removal of software from a repository could compromise Its behavioral Integrity, this step Is controlled. 

• The requester sends the server an Uninstall message. This message Indicates the work to be unlnstalled, the 
version of the Uninstall right being invoked, and the file data for the wori< (Including its size). 

• The repositories perfomn the common opening transaction steps. 

55 • The requester extracts a copy of the digital certificate for the software. If the certificate cannot be found or the 
master repository for the certificate is not known to the requester, the transaction ends with an error. 

• The requester checks whether the software is Installed. If the software is not installed, the transaction ends with 
an error. 
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• The requester decrypts the digital certificate using the public key of the master repository, recording the Identity 
of the supplier and creator, a key for decrypting the software, the compatibility Infomnatlon, and a tamper-checking 
code. (This step authenticates the certification of the software, including the script for uninstalling it.) 

• The requester decrypts the software using the key from the certificate and computes a check code on It using a 
s 1'Way hash function. If the check-code does not match the tamper-checking code from the certificate, the Instal- 
lation transaction ends with an error. (This step assures that the contents of the software, including the various 
scripts, have not been tampered with.) 

• The requester retrieves the Instructions in the uninstaliation script and follows them. If there Is an en^or In this 
process (such as Insufficient resources), then the transaction ends with an error. 

10 • The repositories perform the common closing transaction steps. 



Claims 

IS 1 . A system for controlling the distribution and use of digital works comprising: 

means for associating one or more usage rights (704) to a digital wori< (510-513), each of said one or more 
usage rights (704) specifying a particular Instance of how said digital work (510-513) may be used or distrib- 
uted, the possession of a digital ticket being a condition on the exercise of an associated usage right; 

20 

a plurality of repositories (201-204), adapted to enforce said usage rights and to store and exchange digital 
works, each of said repositories comprising: 

one or more storage means (1207) for storing one or more digital works, their associated usage rights 
25 and digital tickets associated with usage rights; 

transaction processing means (1 200) having a request mode of operation for requesting access to a digital 
work, said request specifying a usage right; and 

30 coupling means (1206) for coupling to another of said plurality of repositories across a communications 

medium; 

characterized in that 

each of said usage rights (704) Is capable of specifying a digital ticket; 
35 each transaction processing means further has a server mode of operation for processing requests to access said 
requested digital work based on said usage right specified in said request, the usage rights associated with said 
digital work, and digital tickets associated with said usage rights; wherein access, for exercising the usage right, 
Is granted when the corresponding digital ticket Is presented for said request; and 

each of the plurality of repositories (201 -204) further comprises a generic ticket agent for punching digital tickets 
40 to indicate that an associated usage right has been exercised. 

2. The system according to claim 1 , wherein a usage right may specify a special ticket agent for punching a specified 
digital ticket and said system further comprises one or more authorization repositories (202) containing special 
ticket agents for punching digital tickets. 

45 

3. The system according to claim 1 or 2, wherein said digital ticket comprises a first timestamp part for indicating a 
time when said digital ticket was copied and a second timestamp part for Indicating a time when said digital ticket 
was punched. 

so 4. The system according to one of claims 1 to 3, wherein said generic ticket agent further comprises means for 
detemnlning If a digital ticket is valid and timestamping means (1205) for timestamping digital tickets when they 
are punched. 

5. A method for controlling access to digital works in a computer controlled system for the distribution of digital works, 
55 comprising the steps of: 

a) creating (101) a digital work and a digital ticket for said digital work; 

b) associating a usage right to said digital work, said usage right specifying said digital ticket; 
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c) storing (102) said digital work in a first repository; 

d) storing said digital ticket in a second repository; 

e) said second repository transmitting (104) a request to access said digital work to said first repository, said 
request specifying said usage right; 

5 f) said first repository detennining (1 05) if said second repository has said digital ticket; 

g) if said second repository presents said digital ticket to said first repository, the latter 

punching said digital ticket and 

granting access to said digital work for exercising said usage right; 

h) If said second repository does not present said digital ticket to said first repository, it denies access to said 
10 digital work. 

6. The method according to claim 5, wherein said step of granting access is performed by transmitting (107) said 
digital wori< to said second repository. 

15 7. The method according to claim 5 or 6, wherein the step of storing said digital ticket In a second repository comprises 
storing said digital ticket in a third repository; and 

said second repository acquiring said digital ticket from said third repository. 

8. The method according to claim 7, wherein the step of said second repository acquiring said digital ticket from said 
20 third repository further comprises a step of said second repository copying said digital ticket from said third repos- 
itory for a fee. 

9. The method according to claim 8, wherein 

said digital ticket comprises a first timestamp part for storing a time when said digital ticket was copied and 
25 a second timestamp part for storing a timestamp when said digital ticket was punched, and 

said step of copying said digital ticket from said second repository for a fee further comprises a step of said 
second repository marking said first timestamp part of said digital ticket with a copy timestamp indicating the time 
and date when the copy of said digital ticket was made. 

30 10. The method according to claim 5, wherein the digital ticket indicates a predetemnined number of times that said 

usage right may be exercised, said generic ticket agent punches said digital ticket to indicate an instance of ex- 
ercising said usage right, and said first repository denies access if said digital ticket indicates that the usage right 
has been exercised said predetermined number of times. 

35 11. The method according to claim 5, wherein said usage right species a special ticket agent for punching said digital 
ticket, said first repository forwards said digital ticket presented from the second repository to said special ticket 
agent, and said special ticket agents perfomris the steps of detemriining and punching. 

12. The method according to claim 6, wherein 

40 said digital ticket is distributed to the second repository together with the second digital wori< for a fee, 

said usage right is a copying right pemnitting to copy said digital wori( fomrilng an upgrade to said second 
digital wori<. 

13. The method according to one of claims 5 to 12, wherein before transmitting a request said first and second repos- 
45 itories perfomn a step of initiating (103) a session to insure that said repositories are trustworthy 

14. The method according to one of claims 5 to 13, wherein the presented digital tbket is validated before the step of 
granting access. 

50 15. The method according to one of claims 5 to 9, wherein the punched digital ticket can not be used again for the 
same usage right. 



PatentansprQche 

55 

1. System zum Steuern der Verteilung und Venwendung von digitalen Art^eiten, aufweisend: 

eine Einrtehtung zum Zuordnen eines Oder mehrerer Benutzungsrechte (704) zu einer digitalen Arbeit 
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(51 0-51 3), wobei jedes des einen oder der mehreren Benutzungsrechte (704) einen bestimmten Fall spezif 1- 
ziert, wie die digrtale Arbeit (510-513) verwendet oder vertellt warden kann, wobei der Besitz eines digitalen 
Tickets eine Bedingung bezugiich des Ausubens eines zugeordneten Benutzungsrechts ist; 
eine l^^ehrzahl von Ven/vahrungsstellen (201-204), angepasst so, um die Benutzungsrechte durchzusetzen 
und um digltale Arbelten zu speichern und auszutauschen, wobei jede der Verwahrungsstellen aufweist: 

eine oder mehrere Spelcherelnrichtung(en) (1207) zum Speichern von einer oder mehreren digitalen Ar- 
beit(en), deren zugeordneten Benutzungsrechten und digitalen Tickets, die den Benutzungsrechten zu- 
geordnet sind; 

eineTransaktions-Verarbeitungseinrichtung (1200), die einen Anforderungs-Betriebs Modus zum Anfor- 
dem eines Zugriffs zu einer digitalen Arbeit besitzt, wobei die Anforderung ein Benutzungsrecht spezifi- 
ziert; und 

eine Verbindungselnrichtung (1206) zum Verblnden mit einer anderen der Mehrzahl von VenA^ahrungs- 
stelten uber ein Kommunikationsmedium; 

dadurcli gekennzeichhet, dass 

jedes der Benutzungsrechte (704) dazu geeignet ist, ein digitales Ticket zu spezif izieren; 
jede Transaktions-Verarbeitungseinrichtung weiterhin einen Server-Betriebs-Modus zur Verarbeitung von Anfor- 
derungen, um auf die angeforderte, digitale Arbeit basierend auf dem Benutzungsrecht, das in der Anforderung 
spezifiziert ist, die Benutzungsrechte der digitalen Arbeit, und die digitalen Tickets, die den Benutzungsrechten 
zugeordnet sind zuzugreifen, wobei ein Zugriff, zum Ausuben des Benutzungsrechts, dann erteilt wird, wenn das 
entsprechende, digitale Ticket fur die Anforderung vorhanden ist; und 

jede der Mehrzahl der Verwahrungsstellen (201-204) weiterhin einen Generik-Ticket-Agenten zum Stanzen digi- 
taler Tickets aufweist, um anzuzeigen, dass ein zugeordnetes Benutzungsrecht ausgeiibt worden ist. 

System nach Anspruch 1 , wobei ein Benutzungsrecht einen speziellen Ticket-Agenten zum Stanzen eines spezi- 
fizierten, digitalen Tickets spezifizieren kann und das System weiterhin eine oder mehrere Autorisierungs-Verwah- 
rungsstelie(n) (202), enthaltend spezielle Ticket-Agenten zum Stanzen digitaler Tickets, aufweist. 

System nach Anspruch 1 oder 2, wobei das digitale Ticket einen ersten Zeitstempel-Teil zum Anzeigen einer Zeit, 
wann das digitale Ticket kopiert wurde, und einen zweiten Zeitstempel-Teil zum Anzeigen einer Zeit, wann das 

digitale Ticket gestanzt wurde, aufweist. 

System nach einem der Anspruche 1 bis 3, wobei der Generik-Ticket-Agent weiterhin eine Einrichtung zum Be- 
stimmen, ob ein digitales Ticket giiltig ist, und eine Zeitstempel-Elnrfchtung (1205) fiir ein zeitmdBiges Stempein 
von digitalen Tickets, wenn sie gestanzt werden, aufweist. 

Verfahren zum Steuem eines Zugriffs auf digitale Arbelten in einem mittels Computer gesteuerten System fur die 
Verteilung von digitalen Arbelten, das die Schrltte aufweist: 

a) Erzeugen (1 01) einer digitalen Arbeit und eines digitalen Tickets fur die digitale Arbeit; 

b) Zuordnen eines Benutzungsrechts zu der digitalen Arbeit, wobei das Benutzungsrecht das digitale Ticket 
spezifiziert; 

c) Speichern (102) der digitalen Arbeit in einer ersten Venwahrungsstelle; 

d) Speichern des digitalen Tickets in einer zweiten Venvahrungsstelle; 

e) wobei die zwerte Venivahrungsstelle eine Anforderung, um auf die digitale Arbeit zuzugreifen, zu der ersten 
Verwahrungsstelle iibertragt (104), wobei die Anforderung das Benutzungsrecht spezifiziert; 

f) wobei die erste Venwahrungsstelle bestimmt (1 05), ob die zweite Verwahrungsstelle das digitale Ticket be- 
sitzt; 

g) falls die zweite Verwahrungsstelle das digitate Ticket der ersten VenA^ahrungssteile prdsentiert, dann die 
letztere 

das digitale Ticket stanzt und 

einen Zugriff zu der digitalen Arbeit zur Ausubung des Benutzungsrechts erteiit; 

h) falls die zweite VenArahrungsstelle nicht das digitale Ticket zu der ersten Verwahrungsstelle hin prasentlert, 
sie einen Zugriff zu der digitalen Arbeit verweigert. 

Verfahren nach Anspruch 5, wobei der Schritt eines Erteilens eines Zugriffs durch Ubertragen (1 07) der digitalen 
Arbeit zu der zweiten Verwahrungsstelle durchgefuhrt wird. 
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7. Verf ahren nach Anspruch 5 oder 6, wobei der Schritt eines Speicherns des digitalen Tickets in einer zweiten Ver- 
wahrungsstelle 

ein Speichem des digitalen Tickets in einer diitten Venivalirungsstelle aufweist; und 

die zweite VenA^ahrungsstelle das digitale Ticket von der dritten Venwahrungsstelle akquiriert. 

5 

8. Verfahren nach Ansprucli 7, wobei der Schritt der zweiten Verwahrungsstelle, der das digitale Ticket von der dritten 
Verwahrungsstelle akquiriert, weiterhin einen Schritt der zweiten Verwahrungsstelle eines Kopierens des digitalen 
Tickets von der dritten Verwahrungsstelle fur eine Gebuhr aufweist. 

10 9. Verfahren nach Anspruch 8, wobei 

das digitale Ticket einen ersten Zeitstempel-Teii zum Speichem einer Zeit, wann das digitale Ticket koplert wurde, 
und einen zweiten Zeitstempel-Teil zum Speichem eines Zeitstempels, wann das digitale Ticket gestanzt wurde, 
aufweist, und 

der Schritt eines Kopierens des digitalen Tickets von der zweiten Verwahrungsstelle fur eine Gebuhr weiterhin 
15 einen Schritt der zweiten Verwahmngsstelle aufweist, den ersten Zeitstempel-Tell des digitalen Tickets mit einem 

Kopie-Zeitstempel zu mari<leren, der die Zeit und das Datum anzeigt, zu denen die Kopie des digitalen Tickets 
vorgenommen wurde. 

10. Verfahren nach Anspruch 5, wobei das digitale Ticket eine vorbestimmte Anzahl von Malen anzeigt, fur die das 
20 Benutzungsrecht ausgeubt werden kann, wobei der Generik-Tlcket-Agent das digitale Ticket stanzt, urn einen Fall 

einer Ausubung des Benutzungsrechts anzuzelgen, und die erste Verwahrungsstelle einen Zugang venwelgert, 
wenn das digitale Ticket anzeigt, dass das Benutzungsrecht die vorbestimmte Anzahl von iVtaien ausgeubt worden 
ist. 

25 11 . Verfahren nach Anspruch 5, wobei das Benutzungsrecht einen speziellen Ticket-Agenten zum Stanzen des digi- 
talen Tickets spezrflziert, wobei die erste Verwahrungsstelle das digitale Ticket, prasentiert von der zweiten Ver- 
wahrungsstelle, zu dem speziellen Tlcket-Agenten weiterfuhrt und die speziellen Tlcket-Agenten die Schritte eines 
Bestimmens und Stanzens durchfCihren. 

30 12. Verfahren nach Anspruch 6, wobei 

das digitale Ticket zu der zweiten Venwahrungssteile zusammen mit der zweiten, digitalen Arbeit fOr eine Gebuhr 

verteilt wird, 

das Benutzu ngsrecht eIn Koplen^echt ist, das emnogllcht, die digitale Arbeit, einen Upgrade in Bezug auf die zweite, 
digitale Arbeit bildend, zu kopieren. 

35 

13. Verfahren nach einem der AnsprucheS bis 12, wobei, vor einem Ubertragen einer Anfordemng, die erste und die 
zweite VenA/ahrungsstelle einen Schritt eines Initiierens (1 03) einer Sitzung durchfuhren, um sicherzustellen, dass 
die Venvahrungsstellen vertrauenswurdig sind. 

40 14. Verfahren nach einem der Anspruche 5 bis 1 3, wobei das prasentlerte, digitale Ticket fur gultig erkiart wird, bevor 
der Schritt eines Erteilens eines Zugriffs vorgenommen wird. 

15. Verfahren nach einem der Anspruche 5 bis 9, wobei das gestanzte, digitale Ticket nicht emeut fur dasselbe Be- 
nutzungsrecht verwendet werden kann. 

45 

Revendications 

1 . Syst^me pour commander la distribution et I'utilisation d'oeuvres num6riques, comprenant : 

50 

des moyens pour associer un ou plusieurs droits d'usage (704) k une oeuvre num6rique (510-513), chacun 
desdits un ou plusieurs droits d'usage (704) sp6clflant un cas partlculler de lafagon dont ladlte oeuvre num§- 
rique (510-513) peut etre utilisee ou distribute, la possession d'un ticket num6rique etant une condition pour 
exercer un droit d'usage associt ; 
55 - une plurality de repertoires (201 -204), adaptts pour faire valoir lesdits droits d'usage et pour stocker et 6chan- 

ger des oeuvres num6riques, chacun desdits repertoires comprenant : 

- - un ou plusieurs moyens de stockage (1207) pour stocker une ou plusieurs oeuvres numSriques, leurs 
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droits d'usage assocles et des tickets num^riques associ^s aux droits d'usage ; 

- - des moyens de traitement de transaction (1 200) poss6dant un mode op^rationnel de demande pour de- 

mander I'accds k une oeuvre numerique, ladite demande sp^ifiant un droit d'usage ; et 

- - des moyens de couplage (1206) pour un couplage k un autre de ladite plurality de repertoires k travers 

un support de communications ; 

caracterise en ce que : 

chacun desdits droits d'usage (704) est capable de sp^ifier un ticket num§rlque ; 

chaque moyen de traitement de transaction poss^de en outre un mode op^rationnel de sen/eur pour traiter 
des demandes afin d'acc^der k ladite oeuvre numerique demand^e en fonction dudit droit d'usage specific 
dans ladite demande, des droits d*usage associ6s k ladite oeuvre numerique et de tickets numerlques assocles 
auxdits droits d'usage ; et 

dans tequel I'acces, pour exercer le droit d'usage, est accord^ lorsque le ticket numerique correspondant 
est presente pour ladite demande, 

chacun de la pluraiite de repertoires (201-204) comprend en outre un agent de ticket g6n§rique pour poin- 
9onner des tickets num^riques afin d'indiquer qu'un droit d'usage associ^ a ei6 exerc§. 

Systeme selon la revendication 1, dans lequel un droit d'usage peut specifier un agent de ticket special pour 
poingonner un ticket numerique specifie et ledit systeme comprend en outre un ou plusieurs repertoires d'autoh- 
sation (202) contenant des agents de ticket special pour poingonner des tickets numerlques. 

Systeme selon la revendication 1 ou 2, dans lequel ledit ticket numerique comprend une premiere partie horodatrice 
pour indiquer un temps auquel ledit ticket numerique a ete copie et une deuxieme partie horodatrice pour Indlquer 
un temps auquel ledit ticket numerique a ete poingonne. 

Systeme selon I'une quelconque des revendications 1 k 3, dans lequel ledit agent de ticket generique comprend 
en outre des moyens pour determiner si un ticket numerique est valide et des moyens horodateurs (1205) pour 
que des tickets numeriques soient horodates lorsqu'ils sent poingonnes. 

Precede pour commander I'acces k des oeuvres numeriques dans un systeme infomnatise pour la distribution 
d'oeuvres numeriques, comprenant les etapes de : 

a) creation (101) d'une oeuvre numerique et d'un ticket numerique pour ladite oeuvre numerique ; 

b) association d'un droit d'usage k ladite oeuvre numerique, ledit droit d'usage specif iant ledit ticket numerique ; 

c) stockage (102) de ladite oeuvre numerique dans un premier repertoire ; 

d) stockage dudit ticket numerique dans un deuxieme repertoire ; 

e) ledit deuxieme repertoire transmettant (1 04) une demande d'acces k ladite oeuvre numerique audit premier 
repertoire, ladite demande specifiant ledit droit d'usage ; 

f) ledit premier repertoire detennlnant (105) si ledit deuxieme repertoire possede ledit ticket numerique ; 

g) si ledit deuxieme repertoire presente ledit ticket numerique audit premier repertoire, ce dernier 

poingonnant ledit ticket numerique et 

accordant I'acces k ladite oeuvre numerique pour exercer ledit droit d'usage ; 

h) si ledit deuxieme repertoire ne presente pas ledit ticket numerique audit premier repertoire, 11 refuse Tacces 
k ladite oeuvre numerique. 

Precede selon la revendication 5, dans lequel ladite etape d'accord de i'acces est effectuee en transmettant (1 07) 
ladite oeuvre numerique audit deuxieme repertoire. 

Precede selon la revendication 5 ou 6. dans lequel i'etape de stockage dudit ticket numerique dans un deuxieme 
repertoire comprend : 

le stockage dudit ticket numerique dans un troisieme repertoire ; et 

ledit deuxieme repertoire acquerant ledit ticket numerique depuis ledit troisieme repertoire. 
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8. Procede selon la revendication 7, dans lequel I'^tape d'acquisition dudit ticket num^rique par ledit deuxi^me re- 
pertoire depuis ledit troist^me repertoire comprend en outre une 6tape de copie dudit ticket num^rique dans ledit 
deuxi^me repertoire depuis ledit troisieme repertoire pour une cotisatlon. 

s 9. Precede selon la revendication 8, dans lequel : 

ledit ticket numerlque comprend une premiere partie horodatrice pour stocker un temps auquel ledit ticket 
numerique a ete copie et une deuxieme partie horodatrice pour stocker un horodateur iorsque ledit ticket 
numeiique a ete poingonne ; et 
10 . ladite etape de copie dudit ticket numerlque depuis ledit deuxieme repertoire pour une cotisation comprend 

en outre une etape de marquage de iadlte premiere partie horodatrtee dudit ticket numerique par iedit deuxieme 
repertoire avec un horodateur de copie Indiquant le temps et la date ou la copie dudit ticket numerlque a ete 
faite. 

15 10. Precede selon la revendication 5, dans lequel le ticket numerique indique un nombre predetermine de fois que 
ledit droit d'usage peut etre exerce, ledit agent de ticket gen6rique poingonne ledit ticket numerique afin d'indiquer 
un cas d'exercice dudit droit d'usage, et ledit premier repertoire refuse I'acces si ledit ticket numerique indique que 
le droit d'usage a ete exerce ledit nombre predetemiine de fois. 

20 11. Precede selon la revendication 5, dans lequel le droit d'usage spedfie un agent de ticket special pour poingonner 
ledit ticket numerique, ledit premier repertoire transfere ledit ticket numerique presente depuis le deuxieme reper- 
toire audit agent de ticket special, et ledit agent de ticket special effectue les etapes de determination et de poin- 
gonnage. 

25 12. Precede selon la revendication 6, dans lequel : 

- ledit ticket numerique est distribue au deuxieme repertoire avec ta deuxieme oeuvre numerique pour une 
cotisation ; et 

ledit droit d'usage est un droit de reproduction pemnettant de copier ladite oeuvre numerique fomriant une 
30 amelioration pour ladite deuxieme oeuvre numerique. 

13. Precede selon I'une quetconque des revendications 5 ^ 12, dans lequel avant de transmettre une demande, lesdits 
premier et deuxieme repertoires effectuent une etape de lancement (1 03) d'une session afin d'assurer que lesdits 
repertoires sent dignes de confiance. 

35 

14. Procede selon I'une quelconque des revendlcatlons 5 k 13, dans lequel le ticket numerique presente est valide 
avant retape d'accord de I'acces. 

15. Procede selon I'une quelconque des revendlcatlons 5^9, dans lequel le ticket numerique poingonne ne peut plus 
40 etre utilise pour le mdme droit d'usage. 
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1S01 -^Mgital Work Rights: = (Rights*) 

1 502— Right : = (Right-Code {Copy-Count} {Control-Spec} {Time^pec} 
{Access-Spec} {Fee-Spec}) 
fSOS -^Right-Code : = Render-Code | Transport-Code | File-Management- 
Code) Derivative-Works- Code | Configuration-Code 
7504— Render-Code ; = [ Play : {Player: Player-ED} | Print {Printer Printer-ID}] 
1505^Transport-Code := [Copy | Transfer | Loan {Remaining-Rights: 

Next-Set-of-Right8}]{(Next-Copy-Right3:NextSet-of-Rights)} 
f 50ff— File-Management-Code := Backup {Back-Up-Copy-Rights: 

Nezt-Set-of-Rights} | Restore | Delete | Folder 
I Directory {Name: Hide-Local | Hide-Remote} 
{Parts: Hide-Local | Hide-Remote} 
fSOZ^Derivative- Works-Code : = [Eictract | Embed | Edit{Process: 

Process-ID}] {Nezt-Copy-Rights : 
Nezt-Set-ofRights} 
7505^Configuration-Code : ^ Install { Uninstall 
1509— Next.Set.of-Rights:= {(Add: Set-Of-Rights)} {(Delete: 

Set-Of-Rights)} {(Replace: Set-Of-Rights )}{(Keep: Set-Of-Rights )} 
751 0'-^Copy-Connt : = (Copiesrpositive-integer 1 0 i Unlimited) 
f 5f f '^Control-Spec : = (Control: {Restrictable | Unrestrictable} 

{Unchargeable ( Chargeable}) 
1572 -^Time-Spec := ({Fixed-Interval | Sliding-Interval i Meter-Time} 
Until: Expiration-Date) 
7573^ — ' Fixed-Interval := From: Start-Time 
7574^ — 'Sliding-Intervai := Interval: Use-Diuration 
7575 — -Meter-Time: = Time-Remaining: Remaining-Use 
7575— Access-Spec ({SC: Security-Class} {Authorization: Auihorization-ID'i'} 

{Otikier-Authorization: Authorization-ID*} {Ticket: Ticket-ID}) 
757 /'^Fee-Spec: s {Scheduled-Diacount} Regular-Fee-Spec | Scheduled-Fee-Spec | 
Markup-Spec 

757S'^Scheduled-Discount:= Scheduled-Discount: (Scheduled-Discount: 

(Time-Spec Percentage)*) 
7579^Regular-Fee-Spec:= ({Fee: | Incentive:} IPer-Use-Spec I Metered-Rate- 

Spec I Best-Price-Spec | Call-For-Price-Specl 
{Min;* Money-Unit Per: Time-Spec}{MaaK 
Money-Unit Per: Time-Spec} To: Account-ID) 
7520'^Per-Use-Spec:=: Per-Use: Money-unit 
7527^Metered-Rate-Spec ;= Metered: Money-Unit Per: Time-Spec 
7522'^Best-Price-Spec : = Best-Price: Money-unit Max: Money-unit 
752J.'>-'Call-For-Price-Spec := Call-For -Price 
.7524'SriScheduIed-Fee-Spec:=: (Schedule: (Time-Spec Regular-Fee-Spec)* ) 
7525' — 'Markup-Spec: = Markup: percentage To: Account-ID 
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